Re: [RFCv2 PATCH 0/5] tuner-core: fix s_std and s_tuner

2011-06-16 Thread Hans Verkuil
On Wednesday, June 15, 2011 22:49:39 Devin Heitmueller wrote:
 On Wed, Jun 15, 2011 at 4:37 PM, Hans Verkuil hverk...@xs4all.nl wrote:
  But the driver has that information, so it should act accordingly.
 
  So on first open you can check whether the current input has a tuner and
  power on the tuner in that case. On S_INPUT you can also poweron/off 
  accordingly
  (bit iffy against the spec, though). So in that case the first use case 
  would
  actually work. It does require that tuner-core.c supports s_power(1), of 
  course.
 
 This will get messy, and is almost certain to get screwed up and cause
 regressions at least on some devices.

I don't see why this should be messy. Anyway, this is all theoretical as long
as tuner-core doesn't support s_power(1). Let's get that in first.

  BTW, I noticed in tuner-core.c that the g_tuner op doesn't wake-up the tuner
  when called. I think it should be added, even though most (all?) tuners will
  need time before they can return anything sensible.
 
 Bear in mind that some tuners can take several seconds to load
 firmware when powered up.  You don't want a situation where the tuner
 is reloading firmware continuously, the net result being that calls to
 v4l2-ctl that used to take milliseconds now take multiple seconds.

Yes, but calling VIDIOC_G_TUNER is a good time to wake up the tuner :-)

  BTW2: it's not a good idea to just broadcast s_power to all subdevs. That 
  should
  be done to the tuner(s) only since other subdevs might also implement 
  s_power.
  For now it's pretty much just tuners and some sensors, though.
 
  You know, this really needs to be a standardized module option and/or sysfs
  entry: 'always on', 'wake up on first open', 'wake up on first use'.
 
 That would definitely be useful, but it shouldn't be a module option
 since you can have multiple devices using the same module.

Of course, I forgot about that.

 It really
 should be an addition to the V4L API.

This would actually for once be a good use of sysfs.

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: no mmu on videobuf2

2011-06-16 Thread Scott Jiang
2011/6/16 Marek Szyprowski m.szyprow...@samsung.com:
 Hello Scott,

 Hi Marek and Laurent,

 I am working on v4l2 drivers for blackfin which is a no mmu soc.
 I found videobuf allocate memory in mmap not reqbuf, so I turn to videobuf2.
 But __setup_offsets() use plane offset to fill m.offset, which is
 always 0 for single-planar buffer.
 So pgoff in get_unmapped_area callback equals 0.
 I only found uvc handled get_unmapped_area for no mmu system, but it
 manages buffers itself.
 I really want videobuf2 to manage buffers. Please give me some advice.

 I'm not really sure if I know the differences between mmu and no-mmu
 systems (from the device driver perspective). I assume that you are using
 videobuf2-vmalloc allocator. Note that memory allocators/managers are well
 separated from the videobuf2 logic. If it the current one doesn't serve you
 well you can make your own no-mmu allocator. Later once we identify all
 differences it might be merged with the standard one or left alone if the
 merge is not really possible or easy.

 Best regards
 --
 Marek Szyprowski
 Samsung Poland RD Center




Hi Marek,

I used dma-contig allocator. I mean if offset is 0, I must get actual
addr from this offset.
__find_plane_by_offset can do this. But it is an internal function.
I think there should be a function called vb2_get_unmapped_area to do
this in framework side.

Regards,
Scott
--
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: [Linaro-mm-sig] [PATCH 08/10] mm: cma: Contiguous Memory Allocator added

2011-06-16 Thread Arnd Bergmann
On Thursday 16 June 2011 02:48:12 Philip Balister wrote:
 On 06/15/2011 12:37 AM, Arnd Bergmann wrote:
  On Wednesday 15 June 2011 09:11:39 Marek Szyprowski wrote:
  I see your concerns, but I really wonder how to determine the properties
  of the global/default cma pool. You definitely don't want to give all
  available memory o CMA, because it will have negative impact on kernel
  operation (kernel really needs to allocate unmovable pages from time to
  time).
 
  Exactly. This is a hard problem, so I would prefer to see a solution for
  coming up with reasonable defaults.
 
 Is this a situation where passing the information from device tree might 
 help? I know this does not help short term, but I am trying to 
 understand the sorts of problems device tree can help solve.

The device tree is a good place to describe any hardware properties such
as 'this device will need 32 MB of contiguous allocations on the memory
bank described in that other device node'.

It is however not a good place to describe user settings such as 'I want
to give this device a 200 MB pool for large allocations so I can run
application X efficiently', because that would require knowledge in the
boot loader about local policy, which it should generally not care about.

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


DVB_NET help message is useless

2011-06-16 Thread Jiri Slaby
Hi,

I've just updated to 3.0-rc and saw CONFIG_DVB_NET. Hmm, let's see
what's that by asking with '?'. And I got this crap:

CONFIG_DVB_NET:

The DVB network support in the DVB core can
optionally be disabled if this
option is set to N.

If unsure say Y.

Why do you think this help message is useful? It's clear to
everybody that if one eventually disables it it will be disabled. The
help message should mention _what_ the network support is.

I would send a patch, but I really have no idea what's that good for.

thanks,
-- 
js
--
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: no mmu on videobuf2

2011-06-16 Thread Kassey Lee
2011/6/16 Scott Jiang scott.jiang.li...@gmail.com:
 2011/6/16 Marek Szyprowski m.szyprow...@samsung.com:
 Hello Scott,

 Hi Marek and Laurent,

 I am working on v4l2 drivers for blackfin which is a no mmu soc.
 I found videobuf allocate memory in mmap not reqbuf, so I turn to videobuf2.
 But __setup_offsets() use plane offset to fill m.offset, which is
 always 0 for single-planar buffer.
 So pgoff in get_unmapped_area callback equals 0.
 I only found uvc handled get_unmapped_area for no mmu system, but it
 manages buffers itself.
 I really want videobuf2 to manage buffers. Please give me some advice.

 I'm not really sure if I know the differences between mmu and no-mmu
 systems (from the device driver perspective). I assume that you are using
 videobuf2-vmalloc allocator. Note that memory allocators/managers are well
 separated from the videobuf2 logic. If it the current one doesn't serve you
 well you can make your own no-mmu allocator. Later once we identify all
 differences it might be merged with the standard one or left alone if the
 merge is not really possible or easy.

 Best regards
 --
 Marek Szyprowski
 Samsung Poland RD Center




 Hi Marek,

 I used dma-contig allocator. I mean if offset is 0, I must get actual
 addr from this offset.
hi, Scott

if it is single plane, surely the offset is 0 for plane 0
what do you mean the actual addr ?


 __find_plane_by_offset can do this. But it is an internal function.
 I think there should be a function called vb2_get_unmapped_area to do
 this in framework side.
are you using soc_camera ?
you can add your get_unmapped_area  in soc_camera.
if not, you can add it in your v4l2_file_operations ops, while still
using videbuf2 to management your buffer.

 Regards,
 Scott
 --
 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




-- 
Best regards
Kassey
Application Processor Systems Engineering, Marvell Technology Group Ltd.
Shanghai, China.
--
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: no mmu on videobuf2

2011-06-16 Thread Scott Jiang
Hi Kassey,

2011/6/16 Kassey Lee kassey1...@gmail.com:
 2011/6/16 Scott Jiang scott.jiang.li...@gmail.com:
 2011/6/16 Marek Szyprowski m.szyprow...@samsung.com:
 Hello Scott,

 Hi Marek and Laurent,

 I am working on v4l2 drivers for blackfin which is a no mmu soc.
 I found videobuf allocate memory in mmap not reqbuf, so I turn to 
 videobuf2.
 But __setup_offsets() use plane offset to fill m.offset, which is
 always 0 for single-planar buffer.
 So pgoff in get_unmapped_area callback equals 0.
 I only found uvc handled get_unmapped_area for no mmu system, but it
 manages buffers itself.
 I really want videobuf2 to manage buffers. Please give me some advice.

 I'm not really sure if I know the differences between mmu and no-mmu
 systems (from the device driver perspective). I assume that you are using
 videobuf2-vmalloc allocator. Note that memory allocators/managers are well
 separated from the videobuf2 logic. If it the current one doesn't serve you
 well you can make your own no-mmu allocator. Later once we identify all
 differences it might be merged with the standard one or left alone if the
 merge is not really possible or easy.

 Best regards
 --
 Marek Szyprowski
 Samsung Poland RD Center




 Hi Marek,

 I used dma-contig allocator. I mean if offset is 0, I must get actual
 addr from this offset.
 hi, Scott

 if it is single plane, surely the offset is 0 for plane 0
yes, it is absolutely right.

 what do you mean the actual addr ?
I should return virtual address of the buffer in get_unmapped_area callback.



 __find_plane_by_offset can do this. But it is an internal function.
 I think there should be a function called vb2_get_unmapped_area to do
 this in framework side.
 are you using soc_camera ?
 you can add your get_unmapped_area  in soc_camera.
 if not, you can add it in your v4l2_file_operations ops, while still
 using videbuf2 to management your buffer.
yes, I have added this method, just copy __find_plane_by_offset code.
But it is ugly, it should have a vb2_get_unmapped_area like vb2_mmap.
These two operations are called by one system call, so they should
have a uniform looks.

Regards,
Scott
--
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: DVB_NET help message is useless

2011-06-16 Thread Hans Petter Selasky
On Thursday 16 June 2011 09:06:59 Jiri Slaby wrote:
 I would send a patch, but I really have no idea what's that good for.

DVB network support is referring to the IP stack. This option is set to N 
when compiling the Linux DVB stack on systems without IP networking.

Please submit a patch if you need a better description.

--HPS
--
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: uvcvideo failure under xHCI

2011-06-16 Thread Laurent Pinchart
Hi Sarah,

On Thursday 16 June 2011 04:59:57 Sarah Sharp wrote:
 On Wed, Jun 15, 2011 at 06:39:57PM -0700, Sarah Sharp wrote:
  When I plug in a webcam under an xHCI host controller in 3.0-rc3+
  (basically top of Greg's usb-linus branch) with xHCI debugging turned
  on, the host controller occasionally cannot keep up with the isochronous
  transfers, and it tells the xHCI driver that it had to skip several
  microframes of transfers.  These Missed Service Intervals aren't
  supposed to be fatal errors, just an indication that something was
  hogging the PCI memory bandwidth.
  
  The xHCI driver then sets the URB's status to -EXDEV, to indicate that
  some of the iso_frame_desc transferred, and sets at least one frame's
 
  status to -EXDEV:
 ...
 
  The urb-status causes uvcvideo code in
  uvc_status.c:uvc_status_complete() to fail with the message:
  
  Jun 15 17:37:11 talon kernel: [  117.987769] uvcvideo: Non-zero status
  (-18) in video completion handler.
 
 ...
 
  I've grepped through drivers/media/video, and it seems like none of the
  drivers handle the -EXDEV status.  What should the xHCI driver be
  setting the URB's status and frame status to when the xHCI host
  controller skips over transfers?  -EREMOTEIO?
  
  Or does it need to set the URB's status to zero, but only set the
  individual frame status to -EXDEV?
 
 Ok, looking at both EHCI and UHCI, they seem to set the urb-status to
 zero, regardless of what they set the frame descriptor field to.
 
 Alan, does that seem correct?

According to Documentation/usb/error-codes.txt, host controller drivers should 
set the status to -EXDEV. However, no device drivers seem to handle that, 
probably because the EHCI/UHCI drivers don't use that error code.

Drivers are clearly out of sync with the documentation, so we should fix one 
of them.

 I've created a patch to do the same thing in the xHCI driver, and I seem
 to be getting consistent video with xHCI debugging turned on, despite
 lots of Missed Service Interval events.

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


RTL2831U wont compile against 2.6.38

2011-06-16 Thread Thomas Holzeisen
Hi there,

I tried to get an RTL2831U dvb-t usb-stick running with a more recent kernel 
(2.6.38) and failed.

The hg respository ~jhoogenraad/rtl2831-r2 aborts on countless drivers, the rc 
coding seem have to
changed a lot since it got touched the last time.

The hg respository ~anttip/rtl2831u wont compile as well, since its even older.

The recent git respositories for media_tree and anttip dont contain drivers for 
the rtl2831u.

Has this device been abandoned, or is anyone working on it?

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


RE: no mmu on videobuf2

2011-06-16 Thread Marek Szyprowski
Hello,

On Thursday, June 16, 2011 9:57 AM Scott Jiang wrote:

(snipped)

  I used dma-contig allocator. I mean if offset is 0, I must get actual
  addr from this offset.
  hi, Scott
 
  if it is single plane, surely the offset is 0 for plane 0
 yes, it is absolutely right.
 
  what do you mean the actual addr ?
 I should return virtual address of the buffer in get_unmapped_area callback.
 
 
 
  __find_plane_by_offset can do this. But it is an internal function.
  I think there should be a function called vb2_get_unmapped_area to do
  this in framework side.
  are you using soc_camera ?
  you can add your get_unmapped_area  in soc_camera.
  if not, you can add it in your v4l2_file_operations ops, while still
  using videbuf2 to management your buffer.
 yes, I have added this method, just copy __find_plane_by_offset code.
 But it is ugly, it should have a vb2_get_unmapped_area like vb2_mmap.
 These two operations are called by one system call, so they should
 have a uniform looks.

If videobuf2-core and its memory allocator interface lacks some operations
that are essential for no-mmu systems, please just add them. Frankly I have
no experience with Linux no-mmu systems, so I might have missed something
that is required for no-mmu case.

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: no mmu on videobuf2

2011-06-16 Thread Laurent Pinchart
Hi Scott,

On Thursday 16 June 2011 09:57:05 Scott Jiang wrote:
 2011/6/16 Kassey Lee kassey1...@gmail.com:
  2011/6/16 Scott Jiang scott.jiang.li...@gmail.com:
  2011/6/16 Marek Szyprowski m.szyprow...@samsung.com:
  Hi Marek and Laurent,
  
  I am working on v4l2 drivers for blackfin which is a no mmu soc.
  I found videobuf allocate memory in mmap not reqbuf, so I turn to
  videobuf2. But __setup_offsets() use plane offset to fill m.offset,
  which is always 0 for single-planar buffer.
  So pgoff in get_unmapped_area callback equals 0.
  I only found uvc handled get_unmapped_area for no mmu system, but it
  manages buffers itself.
  I really want videobuf2 to manage buffers. Please give me some advice.
  
  I'm not really sure if I know the differences between mmu and no-mmu
  systems (from the device driver perspective). I assume that you are
  using videobuf2-vmalloc allocator. Note that memory
  allocators/managers are well separated from the videobuf2 logic. If it
  the current one doesn't serve you well you can make your own no-mmu
  allocator. Later once we identify all differences it might be merged
  with the standard one or left alone if the merge is not really
  possible or easy.
  
  I used dma-contig allocator. I mean if offset is 0, I must get actual
  addr from this offset.
  
  if it is single plane, surely the offset is 0 for plane 0
 
 yes, it is absolutely right.
 
  what do you mean the actual addr ?
 
 I should return virtual address of the buffer in get_unmapped_area
 callback.
 
  __find_plane_by_offset can do this. But it is an internal function.
  I think there should be a function called vb2_get_unmapped_area to do
  this in framework side.
  
  are you using soc_camera ?
  you can add your get_unmapped_area  in soc_camera.
  if not, you can add it in your v4l2_file_operations ops, while still
  using videbuf2 to management your buffer.
 
 yes, I have added this method, just copy __find_plane_by_offset code.
 But it is ugly, it should have a vb2_get_unmapped_area like vb2_mmap.
 These two operations are called by one system call, so they should
 have a uniform looks.

I agree with that. get_unmapped_area is a file operation and should be 
implemented using a videobuf2 helper, like vb2_mmap.

-- 
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] v4l: Don't access media entity after is has been destroyed

2011-06-16 Thread Hans Verkuil
On Wednesday, June 15, 2011 10:36:26 Laurent Pinchart wrote:
 Entities associated with video device nodes are unregistered in
 video_unregister_device(). This destroys the entity even though it can
 still be accessed through open video device nodes.
 
 Move the media_device_unregister_entity() call from
 video_unregister_device() to v4l2_device_release() to ensure that the
 entity isn't unregistered until the last reference to the video device
 is released.
 
 Also remove the media_entity_get()/put() calls from v4l2-dev.c. Those
 functions were designed for subdevs, to avoid a parent module from being
 removed while still accessible through board code. They're not currently
 needed for video device nodes, and will oops when a hotpluggable device
 is disconnected during streaming, as media_entity_put() called in
 v4l2_device_release() tries to access entity-parent-dev-driver which
 is set to NULL when the device is disconnected.

Looks good.

Acked-by: Hans Verkuil hans.verk...@cisco.com

Regards,

Hans

 
 Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
 ---
  drivers/media/video/v4l2-dev.c |   36 +++-
  1 files changed, 7 insertions(+), 29 deletions(-)
 
 diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-dev.c
 index 19d5ae2..5dc1fa1 100644
 --- a/drivers/media/video/v4l2-dev.c
 +++ b/drivers/media/video/v4l2-dev.c
 @@ -167,6 +167,12 @@ static void v4l2_device_release(struct device *cd)
  
   mutex_unlock(videodev_lock);
  
 +#if defined(CONFIG_MEDIA_CONTROLLER)
 + if (vdev-v4l2_dev  vdev-v4l2_dev-mdev 
 + vdev-vfl_type != VFL_TYPE_SUBDEV)
 + media_device_unregister_entity(vdev-entity);
 +#endif
 +
   /* Release video_device and perform other
  cleanups as needed. */
   vdev-release(vdev);
 @@ -405,17 +411,6 @@ static int v4l2_open(struct inode *inode, struct file 
*filp)
   /* and increase the device refcount */
   video_get(vdev);
   mutex_unlock(videodev_lock);
 -#if defined(CONFIG_MEDIA_CONTROLLER)
 - if (vdev-v4l2_dev  vdev-v4l2_dev-mdev 
 - vdev-vfl_type != VFL_TYPE_SUBDEV) {
 - entity = media_entity_get(vdev-entity);
 - if (!entity) {
 - ret = -EBUSY;
 - video_put(vdev);
 - return ret;
 - }
 - }
 -#endif
   if (vdev-fops-open) {
   if (vdev-lock  mutex_lock_interruptible(vdev-lock)) {
   ret = -ERESTARTSYS;
 @@ -431,14 +426,8 @@ static int v4l2_open(struct inode *inode, struct file 
*filp)
  
  err:
   /* decrease the refcount in case of an error */
 - if (ret) {
 -#if defined(CONFIG_MEDIA_CONTROLLER)
 - if (vdev-v4l2_dev  vdev-v4l2_dev-mdev 
 - vdev-vfl_type != VFL_TYPE_SUBDEV)
 - media_entity_put(entity);
 -#endif
 + if (ret)
   video_put(vdev);
 - }
   return ret;
  }
  
 @@ -455,11 +444,6 @@ static int v4l2_release(struct inode *inode, struct 
file *filp)
   if (vdev-lock)
   mutex_unlock(vdev-lock);
   }
 -#if defined(CONFIG_MEDIA_CONTROLLER)
 - if (vdev-v4l2_dev  vdev-v4l2_dev-mdev 
 - vdev-vfl_type != VFL_TYPE_SUBDEV)
 - media_entity_put(vdev-entity);
 -#endif
   /* decrease the refcount unconditionally since the release()
  return value is ignored. */
   video_put(vdev);
 @@ -754,12 +738,6 @@ void video_unregister_device(struct video_device *vdev)
   if (!vdev || !video_is_registered(vdev))
   return;
  
 -#if defined(CONFIG_MEDIA_CONTROLLER)
 - if (vdev-v4l2_dev  vdev-v4l2_dev-mdev 
 - vdev-vfl_type != VFL_TYPE_SUBDEV)
 - media_device_unregister_entity(vdev-entity);
 -#endif
 -
   mutex_lock(videodev_lock);
   /* This must be in a critical section to prevent a race with v4l2_open.
* Once this bit has been cleared video_get may never be called again.
 -- 
 1.7.3.4
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
 
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[GIT PULL FOR v3.0] OMAP3 ISP and media controller fixes

2011-06-16 Thread Laurent Pinchart
Hi Mauro,

The following changes since commit 2c53b436a30867eb6b47dd7bab23ba638d1fb0d2:

  Linux 3.0-rc3 (2011-06-13 15:29:59 -0700)

are available in the git repository at:
  git://linuxtv.org/pinchartl/media.git omap3isp-stable-omap3isp

Laurent Pinchart (1):
  v4l: Don't access media entity after is has been destroyed

Ohad Ben-Cohen (1):
  media: omap3isp: fix a potential NULL deref

 drivers/media/video/omap3isp/isp.c |2 +-
 drivers/media/video/v4l2-dev.c |   39 ++-
 2 files changed, 8 insertions(+), 33 deletions(-)

-- 
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: uvcvideo failure under xHCI

2011-06-16 Thread Andy Walls
Sarah Sharp sarah.a.sh...@linux.intel.com wrote:

Hi Laurent,

I think this issue has been happening for a while now, but my recent
patches to remove most of the xHCI debugging


have finally allowed me to
use a webcam under xHCI with debugging on.  Unfortunately, it doesn't
work very well.

When I plug in a webcam under an xHCI host controller in 3.0-rc3+
(basically top of Greg's usb-linus branch) with xHCI debugging turned
on, the host controller occasionally cannot keep up with the
isochronous
transfers, and it tells the xHCI driver that it had to skip several
microframes of transfers.  These Missed Service Intervals aren't
supposed to be fatal errors, just an indication that something was
hogging the PCI memory bandwidth.

The xHCI driver then sets the URB's status to -EXDEV, to indicate that
some of the iso_frame_desc transferred, and sets at least one frame's
status to -EXDEV:

static int skip_isoc_td(struct xhci_hcd *xhci, struct xhci_td *td,
struct xhci_transfer_event *event,
struct xhci_virt_ep *ep, int *status)
{
struct xhci_ring *ep_ring;
struct urb_priv *urb_priv;
struct usb_iso_packet_descriptor *frame;
int idx;

   ep_ring = xhci_dma_to_transfer_ring(ep, le64_to_cpu(event-buffer));
urb_priv = td-urb-hcpriv;
idx = urb_priv-td_cnt; 
frame = td-urb-iso_frame_desc[idx];

/* The transfer is partly done */
*status = -EXDEV;
frame-status = -EXDEV;

/* calc actual length */
frame-actual_length = 0;

/* Update ring dequeue pointer */
while (ep_ring-dequeue != td-last_trb)
inc_deq(xhci, ep_ring, false);
inc_deq(xhci, ep_ring, false);

return finish_td(xhci, td, NULL, event, ep, status, true);
}

The urb-status causes uvcvideo code in
uvc_status.c:uvc_status_complete() to
fail with the message:

Jun 15 17:37:11 talon kernel: [  117.987769] uvcvideo: Non-zero status
(-18) in video completion handler.

It doesn't resubmit the isochronous URB in that case, and the userspace
video freezes.  If I restart the application, the video comes back
until
the next Missed Service Interval event from the xHCI driver.  Ideally,
the video driver would just resubmit the URB, and the xHCI host
controller would complete transfers as best it can.  I think the frames
with -EXDEV status should be treated like short transfers.

I've grepped through drivers/media/video, and it seems like none of the
drivers handle the -EXDEV status.  What should the xHCI driver be
setting the URB's status and frame status to when the xHCI host
controller skips over transfers?  -EREMOTEIO?

Or does it need to set the URB's status to zero, but only set the
individual frame status to -EXDEV?

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

Video drivers don't handle EXDEV probably because it is an error code about 
filesystem links:

http://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_03.html#tag_02_03


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


Re: DVB_NET help message is useless

2011-06-16 Thread Mauro Carvalho Chehab
Em 16-06-2011 04:06, Jiri Slaby escreveu:
 Hi,
 
 I've just updated to 3.0-rc and saw CONFIG_DVB_NET. Hmm, let's see
 what's that by asking with '?'. And I got this crap:
 
 CONFIG_DVB_NET:
 
 The DVB network support in the DVB core can
 optionally be disabled if this
 option is set to N.
 
 If unsure say Y.
 
 Why do you think this help message is useful? It's clear to
 everybody that if one eventually disables it it will be disabled. The
 help message should mention _what_ the network support is.
 
 I would send a patch, but I really have no idea what's that good for.

As Hans answered this option disables the IP stack from the DVB driver. The
IP stack is part of the DVB standard. It is used, for example, by automatic 
firmware updates used on STB's. It can also be used to access the Internet,
via the DVB card, if the network provider supports it.

Before 3.0, this were enabled on all cards. However, if the IP stack is
disabled, this would mean that the entire DVB would also be disabled.
So, this option were added. It may make sense to make it dependent of
CONFIG_EMBEDDED, as normal users should not need to disable it.

Feel free to send us a patch if you want to improve the Kconfig logic or
help message.

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


Re: dual sveon stv22 Afatech af9015 support (kworld clone)

2011-06-16 Thread Emilio David Diaus López
Hello again:

The output for lsusb -vvd 1b80:e401 is:

Bus 001 Device 016: ID 1b80:e401 Afatech
Device Descriptor:
  bLength    18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass    0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0    64
  idVendor   0x1b80 Afatech
  idProduct  0xe401
  bcdDevice    2.00
  iManufacturer   1 AG Sistemas Informaticos
  iProduct    2 SVEON STV22
  iSerial 0
  bNumConfigurations  1
  Configuration Descriptor:
    bLength 9
    bDescriptorType 2
    wTotalLength   46
    bNumInterfaces  1
    bConfigurationValue 1
    iConfiguration  0
    bmAttributes 0x80
  (Bus Powered)
    MaxPower  500mA
    Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber    0
  bAlternateSetting   0
  bNumEndpoints   4
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  0
  bInterfaceProtocol  0
  iInterface  0
  Endpoint Descriptor:
    bLength 7
    bDescriptorType 5
    bEndpointAddress 0x81  EP 1 IN
    bmAttributes    2
  Transfer Type    Bulk
  Synch Type   None
  Usage Type   Data
    wMaxPacketSize 0x0200  1x 512 bytes
    bInterval   0
  Endpoint Descriptor:
    bLength 7
    bDescriptorType 5
    bEndpointAddress 0x02  EP 2 OUT
    bmAttributes    2
  Transfer Type    Bulk
  Synch Type   None
  Usage Type   Data
    wMaxPacketSize 0x0200  1x 512 bytes
    bInterval   0
  Endpoint Descriptor:
    bLength 7
    bDescriptorType 5
    bEndpointAddress 0x84  EP 4 IN
    bmAttributes    2
  Transfer Type    Bulk
  Synch Type   None
  Usage Type   Data
    wMaxPacketSize 0x0200  1x 512 bytes
    bInterval   0
  Endpoint Descriptor:
    bLength 7
    bDescriptorType 5
    bEndpointAddress 0x85  EP 5 IN
    bmAttributes    2
  Transfer Type    Bulk
  Synch Type   None
  Usage Type   Data
    wMaxPacketSize 0x0200  1x 512 bytes
    bInterval   0
Device Qualifier (for other device speed):
  bLength    10
  bDescriptorType 6
  bcdUSB   2.00
  bDeviceClass    0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0    64
  bNumConfigurations  1
Device Status: 0x
  (Bus Powered)
---

now i'm working in the remote controller keytable, i'm looking for the
remote because i forgot where i put it but i expect to find it soon.

thanks for all

Emilio David Diaus López


Re: [RFCv2 PATCH 0/5] tuner-core: fix s_std and s_tuner

2011-06-16 Thread Mauro Carvalho Chehab
Em 16-06-2011 03:21, Hans Verkuil escreveu:
 On Wednesday, June 15, 2011 22:49:39 Devin Heitmueller wrote:
 On Wed, Jun 15, 2011 at 4:37 PM, Hans Verkuil hverk...@xs4all.nl wrote:
 But the driver has that information, so it should act accordingly.

 So on first open you can check whether the current input has a tuner and
 power on the tuner in that case. On S_INPUT you can also poweron/off 
 accordingly
 (bit iffy against the spec, though). So in that case the first use case 
 would
 actually work. It does require that tuner-core.c supports s_power(1), of 
 course.

 This will get messy, and is almost certain to get screwed up and cause
 regressions at least on some devices.
 
 I don't see why this should be messy. Anyway, this is all theoretical as long
 as tuner-core doesn't support s_power(1). Let's get that in first.

Adding s_power to tuner-core is the easiest part. The hardest one is to decide
what would be the proper behaviour. See bellow.

 BTW, I noticed in tuner-core.c that the g_tuner op doesn't wake-up the tuner
 when called. I think it should be added, even though most (all?) tuners will
 need time before they can return anything sensible.

 Bear in mind that some tuners can take several seconds to load
 firmware when powered up.  You don't want a situation where the tuner
 is reloading firmware continuously, the net result being that calls to
 v4l2-ctl that used to take milliseconds now take multiple seconds.

The question is not when to wake up the tuner, but when to put it to sleep.
Really, the big issue is on USB devices, where we don't want to spend lots
of power while the device is not active. Some devices even become hot when
the tuner is not sleeping. As Devin pointed, some devices like tm6000 take
about 30-45 seconds for loading a firmware (ok, it is a broken design. We should
not take it as a good example).

Currently, there's no way to know when a radio device is being used or not.
Even for video, scripts that call v4l-ctl or v4l2-ctl and then start some
userspace application are there for years. We have even an example for
that at the v4l-utils: contrib/v4l_rec.pl.

One possible logic that would solve the scripting would be to use a watchdog
to monitor ioctl activities. If not used for a while, it could send a s_power
to put the device to sleep, but this may not solve all our problems.

So, I agree with Devin: we need to add an option to explicitly control the
power management logic of the device, having 3 modes of operation:
POWER_AUTO - use the watchdogs to poweroff
POWER_ON - explicitly powers on whatever subdevices are needed in
   order to make the V4L ready to stream;
POWER_OFF - Put all subdevices to power-off if they support it.

After implementing such logic, and keeping the default as POWER_ON, we may
announce that the default will change to POWER_AUTO, and give some time for
userspace apps/scripts that need to use a different mode to change their
behaviour. That means that, for example, radio -qf will need to change to
POWER_ON mode, and radio -m should call POWER_OFF.

It would be good if the API would also provide a way to warn userspace that
a given device supports it or not (maybe at VIDIOC_QUERYCTL?).

I think that such API can be implemented as a new V4L control.

 Yes, but calling VIDIOC_G_TUNER is a good time to wake up the tuner :-)

Not really. Several popular devices load firmware based on the standard (the 
ones based
on xc2028/xc3028/xc4000). So, before sending any tuner command, a VIDIOC_S_STD 
is needed.

 BTW2: it's not a good idea to just broadcast s_power to all subdevs. That 
 should
 be done to the tuner(s) only since other subdevs might also implement 
 s_power.
 For now it's pretty much just tuners and some sensors, though.

 You know, this really needs to be a standardized module option and/or sysfs
 entry: 'always on', 'wake up on first open', 'wake up on first use'.

 That would definitely be useful, but it shouldn't be a module option
 since you can have multiple devices using the same module.
 
 Of course, I forgot about that.
 
 It really
 should be an addition to the V4L API.
 
 This would actually for once be a good use of sysfs.
 
 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: RTL2831U wont compile against 2.6.38

2011-06-16 Thread Sascha Wüstemann
Thomas Holzeisen wrote:
 Hi there,
 
 I tried to get an RTL2831U dvb-t usb-stick running with a more recent kernel 
 (2.6.38) and failed.
 
 The hg respository ~jhoogenraad/rtl2831-r2 aborts on countless drivers, the 
 rc coding seem have to
 changed a lot since it got touched the last time.
 
 The hg respository ~anttip/rtl2831u wont compile as well, since its even 
 older.
 
 The recent git respositories for media_tree and anttip dont contain drivers 
 for the rtl2831u.
 
 Has this device been abandoned, or is anyone working on it?
 
 greetings,
 Thomas

There are still people working on it and there is new sources, e.g. look at
http://www.spinics.net/lists/linux-media/msg24890.html
at the very bottom. Worked like a charm at my system with kernel 2.6.39.

I think, there will be announcements later at
http://wiki.zeratul.org/doku.php?id=linux:v4l:realtek:start

Greetings from Braunschweig, Germany.
Sascha
--
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: Some fixes for alsa_stream

2011-06-16 Thread Hans de Goede

Hi,

On 06/15/2011 05:45 PM, Mauro Carvalho Chehab wrote:

snip


1) try to find a common buffer size that are acceptable by both drivers,
as using the same buffer size helps to avoid memcpy's, especially if
mmap mode is enabled;



This is not needed, using the same buffer size does nothing to avoid memcpy's
there are 2 possible scenarios:
1) Use read() + write() like we do now, this means 2 memcpy's in the form
   of copy_to_user to our buffer followed by a copy_from_user, and we don't
   need to care about buffer sizes, we just write the amount of samples we
   managed to read.

2) Properly implemented mmap, in this case we need to do a regular
   memcpy in userspace from the mmap-ed capture buffers to the mmapped
   playback buffers. In this case having indentical buffersizes would
   simplify the code, as it avoids the need to split the memcpy into
   multiple memcpy's when crossing a buffer boundary. But we
   need to handle this case anyways in case we cannot find a shared
   period size. More over mmap mode is a pain and just not worth it IMHO.


2) If the buffer size means that the latency will be more than a reasonable
time interval [1], then fall back to use different periods;


It is better to just aim for the optimal period size right away, this
greatly simplifies the code, as said before trying to get identical buffer
sizes is premature optimization IMHO. xawtv barely registers in top on
my machine and this includes copying over the actual video data from
/dev/video# to shared memory xv pixmaps. If that part does not even
register imagine how little CPU the audio part is using. There is no
need to make the code more complicated for some theoretical performance
gain here, instead we should KISS.

Note that I've just pushed a patch set which includes rewritten period
/ buf size negotiation and a bunch of cleanups in general. This removes
over 150 lines of code, while at the same time making the code more
flexible. It should now work with pretty much any combination of
input / output device (tested with a bt878 input and intel hda,
usb-audio or pulseaudio output).

I've also changed the default -alsa-pb value to default as we should
not be picking something else then the user / distro configured defaults
for output IMHO. The user can set a generic default in alsarc, and override
that on the cmdline if he/she wants, but unless overridden on the cmdline
we should respect the users generic default as specified in his
alsarc.

We could consider making the desired latency configurable, currently
I've hardcoded it to 30 ms (was 38 with the old code on my system) note
that I've chosen to specify the latency in ms rather then in a number
of samples, since it should be samplerate independent IMO.

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: [RFCv2 PATCH 0/5] tuner-core: fix s_std and s_tuner

2011-06-16 Thread Devin Heitmueller
On Thu, Jun 16, 2011 at 7:14 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 One possible logic that would solve the scripting would be to use a watchdog
 to monitor ioctl activities. If not used for a while, it could send a s_power
 to put the device to sleep, but this may not solve all our problems.

 So, I agree with Devin: we need to add an option to explicitly control the
 power management logic of the device, having 3 modes of operation:
        POWER_AUTO - use the watchdogs to poweroff
        POWER_ON - explicitly powers on whatever subdevices are needed in
                   order to make the V4L ready to stream;
        POWER_OFF - Put all subdevices to power-off if they support it.

 After implementing such logic, and keeping the default as POWER_ON, we may
 announce that the default will change to POWER_AUTO, and give some time for
 userspace apps/scripts that need to use a different mode to change their
 behaviour. That means that, for example, radio -qf will need to change to
 POWER_ON mode, and radio -m should call POWER_OFF.

I've considered this idea before, and it's not bad in theory.  The one
thing you will definitely have to watch out for is causing a race
between DVB and V4L for hybrid tuners.  In other words, you can have a
user switching from analog to digital and you don't want the tuner to
get powered down a few seconds after they started streaming video from
DVB.

Any such solution would have to take the above into account.  We've
got a history of race conditions like this and I definitely don't want
to see a new one introduced.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] [media] DocBook: Use base64 for gif/png files

2011-06-16 Thread Christoph Hellwig
On Thu, Jun 16, 2011 at 11:15:19AM -0300, Mauro Carvalho Chehab wrote:
 The patch utility doesn't work with non-binary files. This causes some
 tools to break, like generating tarball targets and the scripts that
 generate diff patches at http://www.kernel.org/pub/linux/kernel/v2.6/.
 
 So, let's convert all binaries to ascii using base64, and add a
 logic at Makefile to convert them back into binaries at runtime.

Given that all the gifs are not just relatively trivial, but also things
that looks like they originated or at least should as vector graphics
I'd recommend to replace them by SVG files.  These also have the benefit
of actually beeing practically patchable.

--
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] usbvision: remove (broken) image format conversion

2011-06-16 Thread Hans de Goede

Hi,

On 06/11/2011 02:13 PM, Mauro Carvalho Chehab wrote:

Hi Hans de G.,

Em 26-04-2011 08:54, Hans de Goede escreveu:

If you could give it a shot that would be great. I've some hardware to
test this with (although I've never actually tested that hardware), so
I can hopefully pick things up if you cannot finish things before you
need to return the hardware.


As Ondrej couldn't work on that while he was with the hardware, could you
please try to address this issue?


I've put it on my to do list, not sure when I'll get around to it though.

Regards,

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


Re: [PATCH] [media] DocBook: Use base64 for gif/png files

2011-06-16 Thread Mauro Carvalho Chehab
Em 16-06-2011 11:25, Christoph Hellwig escreveu:
 On Thu, Jun 16, 2011 at 11:15:19AM -0300, Mauro Carvalho Chehab wrote:
 The patch utility doesn't work with non-binary files. This causes some
 tools to break, like generating tarball targets and the scripts that
 generate diff patches at http://www.kernel.org/pub/linux/kernel/v2.6/.

 So, let's convert all binaries to ascii using base64, and add a
 logic at Makefile to convert them back into binaries at runtime.
 
 Given that all the gifs are not just relatively trivial, but also things
 that looks like they originated or at least should as vector graphics
 I'd recommend to replace them by SVG files.  These also have the benefit
 of actually beeing practically patchable.

This is a good idea, but it would require to re-draw everything, as we don't
have those files vectorized (I might have one or two svg files on an older
tree, as I had to re-generate some graphics that used to be just pdf).

One of the reasons why SVG was not used in the past is that there used to have 
a 
target to generate pdf files, and I think that the DocBook tools available on 
that time weren't capable of working with svg. Not sure if xmlto currently
supports it, but, as we've removed the pdf generation for the media API, 
changing them to svg is ok.

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


Re: uvcvideo failure under xHCI

2011-06-16 Thread Alan Stern
On Thu, 16 Jun 2011, Laurent Pinchart wrote:

 Hi Sarah,
 
 On Thursday 16 June 2011 04:59:57 Sarah Sharp wrote:
  On Wed, Jun 15, 2011 at 06:39:57PM -0700, Sarah Sharp wrote:
   When I plug in a webcam under an xHCI host controller in 3.0-rc3+
   (basically top of Greg's usb-linus branch) with xHCI debugging turned
   on, the host controller occasionally cannot keep up with the isochronous
   transfers, and it tells the xHCI driver that it had to skip several
   microframes of transfers.  These Missed Service Intervals aren't
   supposed to be fatal errors, just an indication that something was
   hogging the PCI memory bandwidth.
   
   The xHCI driver then sets the URB's status to -EXDEV, to indicate that
   some of the iso_frame_desc transferred, and sets at least one frame's
  
   status to -EXDEV:
  ...
  
   The urb-status causes uvcvideo code in
   uvc_status.c:uvc_status_complete() to fail with the message:
   
   Jun 15 17:37:11 talon kernel: [  117.987769] uvcvideo: Non-zero status
   (-18) in video completion handler.
  
  ...
  
   I've grepped through drivers/media/video, and it seems like none of the
   drivers handle the -EXDEV status.  What should the xHCI driver be
   setting the URB's status and frame status to when the xHCI host
   controller skips over transfers?  -EREMOTEIO?
   
   Or does it need to set the URB's status to zero, but only set the
   individual frame status to -EXDEV?
  
  Ok, looking at both EHCI and UHCI, they seem to set the urb-status to
  zero, regardless of what they set the frame descriptor field to.
  
  Alan, does that seem correct?

The description of the behavior of ehci-hcd and uhci-hcd is correct.  
ohci-hcd behaves the same way too.  And they all agree with the 
behavior described in the kerneldoc for struct urb in 
include/linux/usb.h.

 According to Documentation/usb/error-codes.txt, host controller drivers 
 should 
 set the status to -EXDEV. However, no device drivers seem to handle that, 
 probably because the EHCI/UHCI drivers don't use that error code.
 
 Drivers are clearly out of sync with the documentation, so we should fix one 
 of them.

Under the circumstances, the documentation file should be changed.  
Sarah, can you do that along with the change to xhci-hcd?

Alan Stern

--
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: Some fixes for alsa_stream

2011-06-16 Thread Mauro Carvalho Chehab
Em 16-06-2011 09:29, Hans de Goede escreveu:
 Hi,
 
 On 06/15/2011 05:45 PM, Mauro Carvalho Chehab wrote:
 
 snip
 
 1) try to find a common buffer size that are acceptable by both drivers,
 as using the same buffer size helps to avoid memcpy's, especially if
 mmap mode is enabled;

 
 This is not needed, using the same buffer size does nothing to avoid memcpy's
 there are 2 possible scenarios:
 1) Use read() + write() like we do now, this means 2 memcpy's in the form
of copy_to_user to our buffer followed by a copy_from_user, and we don't
need to care about buffer sizes, we just write the amount of samples we
managed to read.
 
 2) Properly implemented mmap, in this case we need to do a regular
memcpy in userspace from the mmap-ed capture buffers to the mmapped
playback buffers. In this case having indentical buffersizes would
simplify the code, as it avoids the need to split the memcpy into
multiple memcpy's when crossing a buffer boundary. But we
need to handle this case anyways in case we cannot find a shared
period size. More over mmap mode is a pain and just not worth it IMHO.
 
 2) If the buffer size means that the latency will be more than a reasonable
 time interval [1], then fall back to use different periods;
 
 It is better to just aim for the optimal period size right away, this
 greatly simplifies the code, as said before trying to get identical buffer
 sizes is premature optimization IMHO. xawtv barely registers in top on
 my machine and this includes copying over the actual video data from
 /dev/video# to shared memory xv pixmaps. If that part does not even
 register imagine how little CPU the audio part is using. There is no
 need to make the code more complicated for some theoretical performance
 gain here, instead we should KISS.

xawtv has an option to use zerocopy, if the X11 v4l driver is loaded and
if the display adapter supports the old overlay mode. It works fine with
a bttv or saa7134 board with an older Nvidia hardware, like FX-5200. This
works also with older ATI hardware.

I intend to make v4l Xorg driver to work with newer display adapters using
texture, but I  didn't have time for it yet. It would be good if we could
do the same for the mmap mode for audio as well, but I don't think this has
a top priority.

 Note that I've just pushed a patch set which includes rewritten period
 / buf size negotiation and a bunch of cleanups in general. This removes
 over 150 lines of code, while at the same time making the code more
 flexible. 

You removed mmap support, but you didn't removed the alsa-mmap option at xawtv.

 It should now work with pretty much any combination of
 input / output device (tested with a bt878 input and intel hda,
 usb-audio or pulseaudio output).

I'll run some tests later with the boards I have here.

 I've also changed the default -alsa-pb value to default as we should
 not be picking something else then the user / distro configured defaults
 for output IMHO. The user can set a generic default in alsarc, and override
 that on the cmdline if he/she wants, but unless overridden on the cmdline
 we should respect the users generic default as specified in his
 alsarc.

While pulseaudio refuses to work via ssh, this is actually a very bad idea.
Xawtv is used by developers to test their stuff, and they generally do it
on a remote machine, with the console captured via tty port, in order to
be able to catch panic messages.

For now, please revert this patch. After having pulseaudio fixed to properly
handle the audio group, I'm ok to re-add it.

 We could consider making the desired latency configurable, currently
 I've hardcoded it to 30 ms (was 38 with the old code on my system) note
 that I've chosen to specify the latency in ms rather then in a number
 of samples, since it should be samplerate independent IMO.

Yeah, having latency configurable sounds a good idea to me.

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


Re: Some fixes for alsa_stream

2011-06-16 Thread Hans de Goede

Hi,

On 06/16/2011 04:38 PM, Mauro Carvalho Chehab wrote:

Em 16-06-2011 09:29, Hans de Goede escreveu:


snip


Note that I've just pushed a patch set which includes rewritten period
/ buf size negotiation and a bunch of cleanups in general. This removes
over 150 lines of code, while at the same time making the code more
flexible.


You removed mmap support, but you didn't removed the alsa-mmap option at xawtv.



Ah, fixed.


It should now work with pretty much any combination of
input / output device (tested with a bt878 input and intel hda,
usb-audio or pulseaudio output).


I'll run some tests later with the boards I have here.



Thanks.


I've also changed the default -alsa-pb value to default as we should
not be picking something else then the user / distro configured defaults
for output IMHO. The user can set a generic default in alsarc, and override
that on the cmdline if he/she wants, but unless overridden on the cmdline
we should respect the users generic default as specified in his
alsarc.


While pulseaudio refuses to work via ssh, this is actually a very bad idea.
Xawtv is used by developers to test their stuff, and they generally do it
on a remote machine, with the console captured via tty port, in order to
be able to catch panic messages.



I'm sure developers are quite capable of creating either an .alsarc, pass
the cmdline option, or change pulseaudio's config to accept non local console
connections.

We should try to have sane user oriented defaults, not developer oriented
defaults.

Also not all developers work the same way you do, so having a certain default
just so it matches your work flow also is a bad idea IMHO.


For now, please revert this patch. After having pulseaudio fixed to properly
handle the audio group, I'm ok to re-add it.


We could consider making the desired latency configurable, currently
I've hardcoded it to 30 ms (was 38 with the old code on my system) note
that I've chosen to specify the latency in ms rather then in a number
of samples, since it should be samplerate independent IMO.


Yeah, having latency configurable sounds a good idea to me.


Done.

Regards,

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


Re: [PATCH 8/8] marvell-cam: Basic working MMP camera driver

2011-06-16 Thread Jonathan Corbet
On Thu, 16 Jun 2011 10:37:37 +0800
Kassey Lee kassey1...@gmail.com wrote:

  +static void mmpcam_power_down(struct mcam_camera *mcam)
  +{
  +       struct mmp_camera *cam = mcam_to_cam(mcam);
  +       struct mmp_camera_platform_data *pdata;
  +/*
  + * Turn off clocks and set reset lines
  + */
  +       iowrite32(0, cam-power_regs + REG_CCIC_DCGCR);
  +       iowrite32(0, cam-power_regs + REG_CCIC_CRCR);
  +/*
  + * Shut down the sensor.
  + */
  +       pdata = cam-pdev-dev.platform_data;
  +       gpio_set_value(pdata-sensor_power_gpio, 0);
  +       gpio_set_value(pdata-sensor_reset_gpio, 0);  

 it is better to have a callback function to controller sensor power on/off.
 and place the callback function in board.c

This is an interesting question, actually.  The problem is that board
files are on their way out; it's going to be very hard to get any more
board files into the mainline going forward.

The mmp-camera driver does depend on a board file, but I've been careful
to restrict things to basic platform data which can just as easily be put
into a device tree.  Power management callbacks don't really qualify.

So it seems that we need to figure out a way to push this kind of
pin/power management down into the sensor-specific code.  Looking at the
subdev stuff, it looks like a bit of thought has been put into that
direction; there's the s_io_pin_config() callback to describe pins to the
sensor.  But it's almost entirely unused.

There is no power up/down callback, currently.  We could ponder on
whether one should be added, or whether this should be handled through the
existing power management code somehow.  I honestly don't know what the
best answer is on this one - will have to do some digging.  Suggestions
welcome.

Thanks,

jon
--
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 2/8] marvell-cam: Separate out the Marvell camera core

2011-06-16 Thread Jonathan Corbet
On Thu, 16 Jun 2011 11:12:03 +0800
Kassey Lee kassey1...@gmail.com wrote:

   2) for mcam_ctlr_stop_dma implementation, I guess you know
 something about the silicon limitation,  but we found it can not pass
 our stress test(1000 times capture test, which will switch format
 between JPEG and YUV again and again).
our solution is :
stop the ccic controller and wait for about one frame transfer
 time, and the stop the sensor.
this passed our stress test. for your info.

Actually, I know very little that's not in the datasheet.  Are you telling
me that there are hardware limitations that aren't documented, and that
the datasheet is not a 100% accurate description of what's going on?  I'm
*shocked* I tell you!

(For the record, with both Cafe and Armada 610, I've found the hardware to
be more reasonable and in accord with the documentation than with many
others.)

In any case, I don't know about the limitation you're talking about here,
could you elaborate a bit?  For stress testing I've run video capture for
weeks at a time, so obviously you're talking about something else.  Sounds
like something I need to know?

3) for videoubuf2, will you use videoubuf2 only or combined
 with soc-camera ? when can your driver for videoubuf2 ready ?

Videobuf2 only.  To be honest, I've never quite understood what soc-camera
buys.  If there's a reason to do a switch, it could be contemplated - but
remember that Cafe is not an SoC device.

The vb2 driver is working now in vmalloc mode, which is probably what Cafe
will need forever.  I do plan to add dma-contig, and, probably, dma-sg
support in the very near future.  If you want, I can post the vmalloc
version later today; I just want to make one more pass over it first.

4) the point is: ccic and sensor driver should be independent,
 and support two CCIC controller.

No disagreement there.  I believe that two controllers should work now -
though there's probably a gotcha somewhere since it's not actually been
tried.  

Thanks,

jon
--
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: Some fixes for alsa_stream

2011-06-16 Thread Mauro Carvalho Chehab
Em 16-06-2011 12:11, Hans de Goede escreveu:

 I've also changed the default -alsa-pb value to default as we should
 not be picking something else then the user / distro configured defaults
 for output IMHO. The user can set a generic default in alsarc, and override
 that on the cmdline if he/she wants, but unless overridden on the cmdline
 we should respect the users generic default as specified in his
 alsarc.

 While pulseaudio refuses to work via ssh, this is actually a very bad idea.
 Xawtv is used by developers to test their stuff, and they generally do it
 on a remote machine, with the console captured via tty port, in order to
 be able to catch panic messages.

 
 I'm sure developers are quite capable of creating either an .alsarc, pass
 the cmdline option, or change pulseaudio's config to accept non local console
 connections.

As far as I noticed, most media developers seems to not be comfortable with 
pulseaudio. Using pulseaudio by default would require more experience from
developers, otherwise nobody will be able to properly support it.

For example, the only way I know that works to remove an audio 
module used by pulseaudio is by doing dirty tricks like: 

while : ; do kill pulseaudio; rmmod audio_module  break; done

I was told that there's a pactl syntax, but I was never able to find how to
make it work, not even on a local console (and I need it supported via ssh).
From other posts, other developers at this ML also didn't discover how to do 
it yet.

A pulseaudio or .alsarc config to enable ssh would be fine, but, again,
that's not obvious.

While developers are not comfortable with pulseaudio, turning it into a default
is a bad idea.

 
 We should try to have sane user oriented defaults, not developer oriented
 defaults.
 
 Also not all developers work the same way you do, so having a certain default
 just so it matches your work flow also is a bad idea IMHO.
 
 For now, please revert this patch. After having pulseaudio fixed to properly
 handle the audio group, I'm ok to re-add it.

 We could consider making the desired latency configurable, currently
 I've hardcoded it to 30 ms (was 38 with the old code on my system) note
 that I've chosen to specify the latency in ms rather then in a number
 of samples, since it should be samplerate independent IMO.

 Yeah, having latency configurable sounds a good idea to me.
 
 Done.

Thanks!

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


Re: [Linaro-mm-sig] [PATCH 08/10] mm: cma: Contiguous Memory Allocator added

2011-06-16 Thread Larry Bassel
On 16 Jun 11 00:06, Arnd Bergmann wrote:
 On Wednesday 15 June 2011 23:39:58 Larry Bassel wrote:
  On 15 Jun 11 10:36, Marek Szyprowski wrote:
   On Tuesday, June 14, 2011 10:42 PM Arnd Bergmann wrote:
   
On Tuesday 14 June 2011 20:58:25 Zach Pfeffer wrote:
 I've seen this split bank allocation in Qualcomm and TI SoCs, with
 Samsung, that makes 3 major SoC vendors (I would be surprised if
 Nvidia didn't also need to do this) - so I think some configurable
 method to control allocations is necessarily. The chips can't do
 decode without it (and by can't do I mean 1080P and higher decode is
 not functionally useful). Far from special, this would appear to be
 the default.
  
  We at Qualcomm have some platforms that have memory of different
  performance characteristics, some drivers will need a way of
  specifying that they need fast memory for an allocation (and would prefer
  an error if it is not available rather than a fallback to slower
  memory). It would also be bad if allocators who don't need fast
  memory got it accidentally, depriving those who really need it.
 
 Can you describe how the memory areas differ specifically?
 Is there one that is always faster but very small, or are there
 just specific circumstances under which some memory is faster than
 another?

One is always faster, but very small (generally 2-10% the size
of normal memory).

Larry

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
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: uvcvideo failure under xHCI

2011-06-16 Thread Sarah Sharp
On Thu, Jun 16, 2011 at 10:35:49AM -0400, Alan Stern wrote:
 On Thu, 16 Jun 2011, Laurent Pinchart wrote:
  On Thursday 16 June 2011 04:59:57 Sarah Sharp wrote:
   On Wed, Jun 15, 2011 at 06:39:57PM -0700, Sarah Sharp wrote:
I've grepped through drivers/media/video, and it seems like none of the
drivers handle the -EXDEV status.  What should the xHCI driver be
setting the URB's status and frame status to when the xHCI host
controller skips over transfers?  -EREMOTEIO?

Or does it need to set the URB's status to zero, but only set the
individual frame status to -EXDEV?
   
   Ok, looking at both EHCI and UHCI, they seem to set the urb-status to
   zero, regardless of what they set the frame descriptor field to.
   
   Alan, does that seem correct?
 
 The description of the behavior of ehci-hcd and uhci-hcd is correct.  
 ohci-hcd behaves the same way too.  And they all agree with the 
 behavior described in the kerneldoc for struct urb in 
 include/linux/usb.h.

Ah, you mean this bit?

 * @status: This is read in non-iso completion functions to get the
 *  status of the particular request.  ISO requests only use it
 *  to tell whether the URB was unlinked; detailed status for
 *  each frame is in the fields of the iso_frame-desc.


  According to Documentation/usb/error-codes.txt, host controller drivers 
  should 
  set the status to -EXDEV. However, no device drivers seem to handle that, 
  probably because the EHCI/UHCI drivers don't use that error code.
  
  Drivers are clearly out of sync with the documentation, so we should fix 
  one 
  of them.
 
 Under the circumstances, the documentation file should be changed.  
 Sarah, can you do that along with the change to xhci-hcd?

Sure.  It feels like there should be a note about which values
isochronous URBs might have in the urb-status field.  The USB core is
the only one that would be setting those, so which values would it set?
uvcvideo tests for these error codes:

case -ENOENT:   /* usb_kill_urb() called. */
case -ECONNRESET:   /* usb_unlink_urb() called. */
case -ESHUTDOWN:/* The endpoint is being disabled. */
case -EPROTO:   /* Device is disconnected (reported by some
 * host controller). */

Are there any others.

Sarah Sharp
--
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: remove unnecessary code

2011-06-16 Thread Greg Dietsche
remove unnecessary code that matches this coccinelle pattern
if (...)
return ret;
return ret;

Signed-off-by: Greg Dietsche gregory.diets...@cuw.edu
---
 drivers/media/dvb/frontends/cx24116.c |6 +-
 1 files changed, 1 insertions(+), 5 deletions(-)

diff --git a/drivers/media/dvb/frontends/cx24116.c 
b/drivers/media/dvb/frontends/cx24116.c
index 95c6465..ccd0525 100644
--- a/drivers/media/dvb/frontends/cx24116.c
+++ b/drivers/media/dvb/frontends/cx24116.c
@@ -1452,11 +1452,7 @@ tuned:  /* Set/Reset B/W */
cmd.args[0x00] = CMD_BANDWIDTH;
cmd.args[0x01] = 0x00;
cmd.len = 0x02;
-   ret = cx24116_cmd_execute(fe, cmd);
-   if (ret != 0)
-   return ret;
-
-   return ret;
+   return cx24116_cmd_execute(fe, cmd);
 }
 
 static int cx24116_tune(struct dvb_frontend *fe, struct 
dvb_frontend_parameters *params,
-- 
1.7.2.5

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


Re: uvcvideo failure under xHCI

2011-06-16 Thread Alan Stern
On Thu, 16 Jun 2011, Sarah Sharp wrote:

Alan, does that seem correct?
  
  The description of the behavior of ehci-hcd and uhci-hcd is correct.  
  ohci-hcd behaves the same way too.  And they all agree with the 
  behavior described in the kerneldoc for struct urb in 
  include/linux/usb.h.
 
 Ah, you mean this bit?
 
  * @status: This is read in non-iso completion functions to get the
  *  status of the particular request.  ISO requests only use it
  *  to tell whether the URB was unlinked; detailed status for
  *  each frame is in the fields of the iso_frame-desc.

Right.  There's also some more near the end:

 * Completion Callbacks:
 *
 * The completion callback is made in_interrupt(), and one of the first
 * things that a completion handler should do is check the status field.
 * The status field is provided for all URBs.  It is used to report
 * unlinked URBs, and status for all non-ISO transfers.  It should not
 * be examined before the URB is returned to the completion handler.

  Under the circumstances, the documentation file should be changed.  
  Sarah, can you do that along with the change to xhci-hcd?
 
 Sure.  It feels like there should be a note about which values
 isochronous URBs might have in the urb-status field.  The USB core is
 the only one that would be setting those, so which values would it set?
 uvcvideo tests for these error codes:
 
 case -ENOENT:   /* usb_kill_urb() called. */
 case -ECONNRESET:   /* usb_unlink_urb() called. */
 case -ESHUTDOWN:/* The endpoint is being disabled. */
 case -EPROTO:   /* Device is disconnected (reported by some
  * host controller). */
 
 Are there any others.

-EREMOTEIO, in the unlikely event that URB_SHORT_NOT_OK is set, but no
others.

And I wasn't aware of that last one...  Host controller drivers should
report -ESHUTDOWN to mean the device has been disconnected, not
-EPROTO.  But usually HCD don't take these events into account when
determining URB status codes.

Alan Stern

--
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: Some fixes for alsa_stream

2011-06-16 Thread Hans de Goede

Hi,

On 06/16/2011 05:35 PM, Mauro Carvalho Chehab wrote:

Em 16-06-2011 12:11, Hans de Goede escreveu:


snip


While developers are not comfortable with pulseaudio, turning it into a default
is a bad idea.



1) Some developers are fine with pulseaudio, so please speak on behalf of
   yourself rather then of developers. Disclaimer I've written patches
   to the alsa code for many a program to work properly with pulseaudio's
   alsa glue layer as well as (re)written the SDL pulseaudio backend.

2) Developers who are not comfortable with pulseaudio now, should better
   learn pulseaudio since that is what the majority of our users are using

3) I'm not making pulseaudio default *at all*. I'm making the default
   alsa device the default. Which seems like a very sane default to me.

Does your default alsa device happen to point to pulseaudio, and you
don't want that, plenty of options:

1) pass -alsa-pb hw to xawtv (requires no pulseaudio knowledge)
2) Set a different default alsa device in .alsarc
   (requires no pulseaudio knowledge, trivial alsa knowledge)
3) Do rpm -e alsa-plugins-pulseaudio

Noe that 3 will permanently make any alsa using app use alsa directly
instead of PA, which seems to be just what you want.

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


New channels list sk-Presov

2011-06-16 Thread Viktor Kristian
Hello.

I would like to commit channel list sk-Presov as suggested in README of
utility scan from dvb-apps.

Please let me know if anything is missing in this list.

Thank You


-- 
S podzravom / Kind regards,
Viktor Kristian
# DVB-T Prešov (Prešov, Slovak Republic)
# Created from http://www.dvbt.towercom.sk/odbornici.php
# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy

# MUX1 - Pilot - on channel 64
T 81800 8MHz 2/3 NONE QAM64 8k 1/4 NONE

# MUX2 - Commercial - on channel 59
T 77800 8MHz 2/3 NONE QAM64 8k 1/4 NONE

# MUX3 - Public - on channel 25
T 50600 8MHz 2/3 NONE QAM64 8k 1/4 NONE



smime.p7s
Description: S/MIME cryptographic signature


Re: Some fixes for alsa_stream

2011-06-16 Thread Mauro Carvalho Chehab
Em 16-06-2011 15:19, Hans de Goede escreveu:
 Hi,

 1) pass -alsa-pb hw to xawtv (requires no pulseaudio knowledge)
 2) Set a different default alsa device in .alsarc
(requires no pulseaudio knowledge, trivial alsa knowledge)
 3) Do rpm -e alsa-plugins-pulseaudio
 
 Noe that 3 will permanently make any alsa using app use alsa directly
 instead of PA, which seems to be just what you want.

Even 3 still doesn't solve rmmod alsa-module

On desktops, an yum remove -y pulseaudio work, but bluetooth depends on it,
so this also doesn't provide a solution for notebooks.

Anyway, for now I'll do it on all my instances with pulseaudio, while
nobody provides a solution for rmmod.

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

2011-06-16 Thread Hans Verkuil
This message is generated daily by a cron job that builds v4l-dvb for
the kernels and architectures in the list below.

Results of the daily build of v4l-dvb:

date:Thu Jun 16 19:00:34 CEST 2011
git hash:f49c454fe981d955d7c3d620f6baa04fb9876adc
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: OK
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: WARNINGS
linux-2.6.33-i686: WARNINGS
linux-2.6.34-i686: WARNINGS
linux-2.6.35.3-i686: WARNINGS
linux-2.6.36-i686: WARNINGS
linux-2.6.37-i686: WARNINGS
linux-2.6.38.2-i686: WARNINGS
linux-2.6.39.1-i686: WARNINGS
linux-2.6.31.12-x86_64: ERRORS
linux-2.6.32.6-x86_64: WARNINGS
linux-2.6.33-x86_64: WARNINGS
linux-2.6.34-x86_64: WARNINGS
linux-2.6.35.3-x86_64: WARNINGS
linux-2.6.36-x86_64: WARNINGS
linux-2.6.37-x86_64: WARNINGS
linux-2.6.38.2-x86_64: WARNINGS
linux-2.6.39.1-x86_64: WARNINGS
spec-git: ERRORS
sparse: ERRORS

Detailed results are available here:

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

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Thursday.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: uvcvideo failure under xHCI

2011-06-16 Thread Sarah Sharp
On Thu, Jun 16, 2011 at 01:39:43PM -0400, Alan Stern wrote:
 On Thu, 16 Jun 2011, Sarah Sharp wrote:
 
 Alan, does that seem correct?
   
   The description of the behavior of ehci-hcd and uhci-hcd is correct.  
   ohci-hcd behaves the same way too.  And they all agree with the 
   behavior described in the kerneldoc for struct urb in 
   include/linux/usb.h.
  
  Ah, you mean this bit?
  
   * @status: This is read in non-iso completion functions to get the
   *  status of the particular request.  ISO requests only use it
   *  to tell whether the URB was unlinked; detailed status for
   *  each frame is in the fields of the iso_frame-desc.
 
 Right.  There's also some more near the end:
 
  * Completion Callbacks:
  *
  * The completion callback is made in_interrupt(), and one of the first
  * things that a completion handler should do is check the status field.
  * The status field is provided for all URBs.  It is used to report
  * unlinked URBs, and status for all non-ISO transfers.  It should not
  * be examined before the URB is returned to the completion handler.
 
   Under the circumstances, the documentation file should be changed.  
   Sarah, can you do that along with the change to xhci-hcd?
  
  Sure.  It feels like there should be a note about which values
  isochronous URBs might have in the urb-status field.  The USB core is
  the only one that would be setting those, so which values would it set?
  uvcvideo tests for these error codes:
  
  case -ENOENT:   /* usb_kill_urb() called. */
  case -ECONNRESET:   /* usb_unlink_urb() called. */
  case -ESHUTDOWN:/* The endpoint is being disabled. */
  case -EPROTO:   /* Device is disconnected (reported by some
   * host controller). */
  
  Are there any others.
 
 -EREMOTEIO, in the unlikely event that URB_SHORT_NOT_OK is set, but no
 others.

Are you saying that the USB core will only set -EREMOTEIO for
isochronous URBs?  Or do you mean that in addition to the status values
that uvcvideo checks, the USB core can also set -EREMOTEIO?

 And I wasn't aware of that last one...  Host controller drivers should
 report -ESHUTDOWN to mean the device has been disconnected, not
 -EPROTO.  But usually HCD don't take these events into account when
 determining URB status codes.

The xHCI driver will return -ESHUTDOWN as a status for URBs when the
host controller is dying.

Sarah Sharp
--
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] OMAP_VOUT: Change hardcoded device node number to -1

2011-06-16 Thread hvaibhav
From: Vaibhav Hiremath hvaib...@ti.com

With addition of media-controller framework, now we have various
device nodes (/dev/videoX) getting created, so hardcoding
minor number in video_register_device() is not recommended.

So let V4L2 framework choose free minor number for the device.

Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
 drivers/media/video/omap/omap_vout.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/omap/omap_vout.c 
b/drivers/media/video/omap/omap_vout.c
index 0bc776c..3bc909a 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -1993,7 +1993,7 @@ static int __init omap_vout_create_video_devices(struct 
platform_device *pdev)
/* Register the Video device with V4L2
 */
vfd = vout-vfd;
-   if (video_register_device(vfd, VFL_TYPE_GRABBER, k + 1)  0) {
+   if (video_register_device(vfd, VFL_TYPE_GRABBER, -1)  0) {
dev_err(pdev-dev, : Could not register 
Video for Linux device\n);
vfd-minor = -1;
-- 
1.6.2.4

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


[PATCH] DVB: dvb-net, make the kconfig text helpful

2011-06-16 Thread Jiri Slaby
Telling the user they can disable an option if they want is not the
much useful. Describe what it is good for instead.

The text was derived from Mauro's email.

Signed-off-by: Jiri Slaby jsl...@suse.cz
Cc: Mauro Carvalho Chehab mche...@redhat.com
Cc: Hans Petter Selasky hsela...@c2i.net
---
 drivers/media/Kconfig |   10 ++
 1 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
index dc61895..279e2b9 100644
--- a/drivers/media/Kconfig
+++ b/drivers/media/Kconfig
@@ -89,11 +89,13 @@ config DVB_NET
default (NET  INET)
depends on NET  INET
help
- The DVB network support in the DVB core can
- optionally be disabled if this
- option is set to N.
+ This option enables DVB Network Support which is a part of the DVB
+ standard. It is used, for example, by automatic firmware updates used
+ on Set-Top-Boxes. It can also be used to access the Internet via the
+ DVB card, if the network provider supports it.
 
- If unsure say Y.
+ You may want to disable the network support on embedded devices. If
+ unsure say Y.
 
 config VIDEO_MEDIA
tristate
-- 
1.7.5.4


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


[PATCH] [media] rc: fix ghost keypresses with certain hw

2011-06-16 Thread Jarod Wilson
With hardware that has to use ir_raw_event_store_edge to collect IR
sample durations, we were not doing an event reset unless
IR_MAX_DURATION had passed. That's around 4 seconds. So if someone
presses up, then down, with less than 4 seconds in between, they'd get
the initial up, then up and down upon pressing down.

To fix this, I've lowered the send a reset event logic's threshold to
the input device's REP_DELAY (defaults to 500ms), and with an
saa7134-based GPIO-driven IR receiver in a Hauppauge HVR-1150, I get
*much* better behavior out of the remote now. Special thanks to Devin
for providing the hardware to investigate this issue.

CC: Devin Heitmueller dheitmuel...@kernellabs.com
Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/rc/ir-raw.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/media/rc/ir-raw.c b/drivers/media/rc/ir-raw.c
index f4efd2f..27808bb 100644
--- a/drivers/media/rc/ir-raw.c
+++ b/drivers/media/rc/ir-raw.c
@@ -114,18 +114,20 @@ int ir_raw_event_store_edge(struct rc_dev *dev, enum 
raw_event_type type)
s64 delta; /* ns */
DEFINE_IR_RAW_EVENT(ev);
int rc = 0;
+   int delay;
 
if (!dev-raw)
return -EINVAL;
 
now = ktime_get();
delta = ktime_to_ns(ktime_sub(now, dev-raw-last_event));
+   delay = MS_TO_NS(dev-input_dev-rep[REP_DELAY]);
 
/* Check for a long duration since last event or if we're
 * being called for the first time, note that delta can't
 * possibly be negative.
 */
-   if (delta  IR_MAX_DURATION || !dev-raw-last_type)
+   if (delta  delay || !dev-raw-last_type)
type |= IR_START_EVENT;
else
ev.duration = delta;
-- 
1.7.1

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


[PATCH] [staging] lirc_serial: allocate irq at init time

2011-06-16 Thread Jarod Wilson
There's really no good reason not to just grab the desired IRQ at driver
init time, instead of every time the lirc device node is accessed. This
also improves the speed and reliability with which a serial transmitter
can operate, as back-to-back transmission attempts (i.e., channel change
to a multi-digit channel) don't have to spend time acquiring and then
releasing the IRQ for every digit, sometimes multiple times, if lircd
has been told to use the min_repeat parameter.

CC: de...@driverdev.osuosl.org
Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/staging/lirc/lirc_serial.c |   44 +--
 1 files changed, 21 insertions(+), 23 deletions(-)

diff --git a/drivers/staging/lirc/lirc_serial.c 
b/drivers/staging/lirc/lirc_serial.c
index 1c3099b..805df91 100644
--- a/drivers/staging/lirc/lirc_serial.c
+++ b/drivers/staging/lirc/lirc_serial.c
@@ -838,7 +838,23 @@ static int hardware_init_port(void)
 
 static int init_port(void)
 {
-   int i, nlow, nhigh;
+   int i, nlow, nhigh, result;
+
+   result = request_irq(irq, irq_handler,
+IRQF_DISABLED | (share_irq ? IRQF_SHARED : 0),
+LIRC_DRIVER_NAME, (void *)hardware);
+
+   switch (result) {
+   case -EBUSY:
+   printk(KERN_ERR LIRC_DRIVER_NAME : IRQ %d busy\n, irq);
+   return -EBUSY;
+   case -EINVAL:
+   printk(KERN_ERR LIRC_DRIVER_NAME
+  : Bad irq number or handler\n);
+   return -EINVAL;
+   default:
+   break;
+   };
 
/* Reserve io region. */
/*
@@ -893,34 +909,17 @@ static int init_port(void)
printk(KERN_INFO LIRC_DRIVER_NAME  : Manually using active 
   %s receiver\n, sense ? low : high);
 
+   dprintk(Interrupt %d, port %04x obtained\n, irq, io);
return 0;
 }
 
 static int set_use_inc(void *data)
 {
-   int result;
unsigned long flags;
 
/* initialize timestamp */
do_gettimeofday(lasttv);
 
-   result = request_irq(irq, irq_handler,
-IRQF_DISABLED | (share_irq ? IRQF_SHARED : 0),
-LIRC_DRIVER_NAME, (void *)hardware);
-
-   switch (result) {
-   case -EBUSY:
-   printk(KERN_ERR LIRC_DRIVER_NAME : IRQ %d busy\n, irq);
-   return -EBUSY;
-   case -EINVAL:
-   printk(KERN_ERR LIRC_DRIVER_NAME
-  : Bad irq number or handler\n);
-   return -EINVAL;
-   default:
-   dprintk(Interrupt %d, port %04x obtained\n, irq, io);
-   break;
-   };
-
spin_lock_irqsave(hardware[type].lock, flags);
 
/* Set DLAB 0. */
@@ -945,10 +944,6 @@ static void set_use_dec(void *data)
soutp(UART_IER, sinp(UART_IER) 
  (~(UART_IER_MSI|UART_IER_RLSI|UART_IER_THRI|UART_IER_RDI)));
spin_unlock_irqrestore(hardware[type].lock, flags);
-
-   free_irq(irq, (void *)hardware);
-
-   dprintk(freed IRQ %d\n, irq);
 }
 
 static ssize_t lirc_write(struct file *file, const char *buf,
@@ -1256,6 +1251,9 @@ exit_serial_exit:
 static void __exit lirc_serial_exit_module(void)
 {
lirc_serial_exit();
+
+   free_irq(irq, (void *)hardware);
+
if (iommap != 0)
release_mem_region(iommap, 8  ioshift);
else
-- 
1.7.1

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


Re: uvcvideo failure under xHCI

2011-06-16 Thread Alan Stern
On Thu, 16 Jun 2011, Sarah Sharp wrote:

   Sure.  It feels like there should be a note about which values
   isochronous URBs might have in the urb-status field.  The USB core is
   the only one that would be setting those, so which values would it set?
   uvcvideo tests for these error codes:
   
   case -ENOENT:   /* usb_kill_urb() called. */
   case -ECONNRESET:   /* usb_unlink_urb() called. */
   case -ESHUTDOWN:/* The endpoint is being disabled. */
   case -EPROTO:   /* Device is disconnected (reported by 
   some
* host controller). */
   
   Are there any others.
  
  -EREMOTEIO, in the unlikely event that URB_SHORT_NOT_OK is set, but no
  others.
 
 Are you saying that the USB core will only set -EREMOTEIO for
 isochronous URBs?  Or do you mean that in addition to the status values
 that uvcvideo checks, the USB core can also set -EREMOTEIO?

The latter.  However, if uvcvideo never sets the URB_SHORT_NOT_OK flag 
then usbcore will never set urb-status to -EREMOTEIO.

  And I wasn't aware of that last one...  Host controller drivers should
  report -ESHUTDOWN to mean the device has been disconnected, not
  -EPROTO.  But usually HCD don't take these events into account when
  determining URB status codes.
 
 The xHCI driver will return -ESHUTDOWN as a status for URBs when the
 host controller is dying.

That's appropriate.  But nobody should ever set an isochronous URB's
status field to -EPROTO, no matter whether the device is connected or
not and no matter whether the host controller is alive or not.

Alan Stern

--
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 8/8] marvell-cam: Basic working MMP camera driver

2011-06-16 Thread Sylwester Nawrocki
Hello,

On 06/16/2011 05:17 PM, Jonathan Corbet wrote:
 On Thu, 16 Jun 2011 10:37:37 +0800
 Kassey Leekassey1...@gmail.com  wrote:
 
 +static void mmpcam_power_down(struct mcam_camera *mcam)
 +{
 +   struct mmp_camera *cam = mcam_to_cam(mcam);
 +   struct mmp_camera_platform_data *pdata;
 +/*
 + * Turn off clocks and set reset lines
 + */
 +   iowrite32(0, cam-power_regs + REG_CCIC_DCGCR);
 +   iowrite32(0, cam-power_regs + REG_CCIC_CRCR);
 +/*
 + * Shut down the sensor.
 + */
 +   pdata = cam-pdev-dev.platform_data;
 +   gpio_set_value(pdata-sensor_power_gpio, 0);
 +   gpio_set_value(pdata-sensor_reset_gpio, 0);
 
 it is better to have a callback function to controller sensor power on/off.
 and place the callback function in board.c

It might be more convenient for the driver writer but I do not think
it is generally better. Platform callbacks cannot really be migrated 
to FDT. For reasons pointed out by Jon below I have also been trying
to avoid callbacks in sensors' platform data.

 
 This is an interesting question, actually.  The problem is that board
 files are on their way out; it's going to be very hard to get any more
 board files into the mainline going forward.
 
 The mmp-camera driver does depend on a board file, but I've been careful
 to restrict things to basic platform data which can just as easily be put
 into a device tree.  Power management callbacks don't really qualify.
 
 So it seems that we need to figure out a way to push this kind of
 pin/power management down into the sensor-specific code.  Looking at the
 subdev stuff, it looks like a bit of thought has been put into that
 direction; there's the s_io_pin_config() callback to describe pins to the

But having sensor's GPIOs configured by bridge driver does not help us
much here, does it? The bridge driver would still need to retrieve the
sensor configuration from somewhere, since it is machine/board specific.
And it's the subdev driver that will know how the GPIOs should be handled,
the timing constraints, etc. So as long as we can pass gpio numbers from
a device tree to subdevs we probably do not need an additional subdev 
operation. 
I guess when there come more subdev drivers dealing with GPIOs we could try
and see what could be generalized.

 sensor.  But it's almost entirely unused.
 
 There is no power up/down callback, currently.  We could ponder on

We have the subdev s_power core operation in struct v4l2_subdev_core_ops.
However it seems that its semantic is not yet clearly documented.

 whether one should be added, or whether this should be handled through the
 existing power management code somehow.  I honestly don't know what the
 best answer is on this one - will have to do some digging.  Suggestions
 welcome.

--
Regards,
Sylwester

--
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: uvcvideo failure under xHCI

2011-06-16 Thread Sarah Sharp
On Thu, Jun 16, 2011 at 03:39:11PM -0400, Alan Stern wrote:
 That's appropriate.  But nobody should ever set an isochronous URB's
 status field to -EPROTO, no matter whether the device is connected or
 not and no matter whether the host controller is alive or not.

But the individual frame status be set to -EPROTO, correct?  That's what
Alex was told to do when an isochronous TD had a completion code of
Incompatible Device Error.

Sarah Sharp
--
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] omap_vout: Added check in reqbuf mmap for buf_size allocation

2011-06-16 Thread hvaibhav
From: Vaibhav Hiremath hvaib...@ti.com

The usecase where, user allocates small size of buffer
through bootargs (video1_bufsize/video2_bufsize) and later from application
tries to set the format which requires larger buffer size, driver doesn't
check for insufficient buffer size and allows application to map extra buffer.
This leads to kernel crash, when user application tries to access memory
beyond the allocation size.

Added check in both mmap and reqbuf call back function,
and return error if the size of the buffer allocated by user through
bootargs is less than the S_FMT size.

Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
 drivers/media/video/omap/omap_vout.c |   16 
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/omap/omap_vout.c 
b/drivers/media/video/omap/omap_vout.c
index 3bc909a..343b50c 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -678,6 +678,14 @@ static int omap_vout_buffer_setup(struct videobuf_queue 
*q, unsigned int *count,
startindex = (vout-vid == OMAP_VIDEO1) ?
video1_numbuffers : video2_numbuffers;

+   /* Check the size of the buffer */
+   if (*size  vout-buffer_size) {
+   v4l2_err(vout-vid_dev-v4l2_dev,
+   buffer allocation mismatch [%u] [%u]\n,
+   *size, vout-buffer_size);
+   return -ENOMEM;
+   }
+
for (i = startindex; i  *count; i++) {
vout-buffer_size = *size;

@@ -856,6 +864,14 @@ static int omap_vout_mmap(struct file *file, struct 
vm_area_struct *vma)
(vma-vm_pgoff  PAGE_SHIFT));
return -EINVAL;
}
+   /* Check the size of the buffer */
+   if (size  vout-buffer_size) {
+   v4l2_err(vout-vid_dev-v4l2_dev,
+   insufficient memory [%lu] [%u]\n,
+   size, vout-buffer_size);
+   return -ENOMEM;
+   }
+
q-bufs[i]-baddr = vma-vm_start;

vma-vm_flags |= VM_RESERVED;
--
1.6.2.4

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


Re: uvcvideo failure under xHCI

2011-06-16 Thread Alan Stern
On Thu, 16 Jun 2011, Sarah Sharp wrote:

 On Thu, Jun 16, 2011 at 03:39:11PM -0400, Alan Stern wrote:
  That's appropriate.  But nobody should ever set an isochronous URB's
  status field to -EPROTO, no matter whether the device is connected or
  not and no matter whether the host controller is alive or not.
 
 But the individual frame status be set to -EPROTO, correct?  That's what
 Alex was told to do when an isochronous TD had a completion code of
 Incompatible Device Error.

Right.  -EPROTO is a perfectly reasonable code for a frame's status.  
But not for an isochronous URB's status.  There's no reason for 
uvcvideo to test for it.

Alan Stern

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


[PATCH] [media] saa7134: fix raw IR timeout value

2011-06-16 Thread Jarod Wilson
The comment says wait 15ms, but the code says jiffies_to_msecs(15)
instead of msecs_to_jiffies(15). Fix that. Tested, works fine with both
rc5 and rc6 decode, in-kernel and via lirc userspace, with an HVR-1150.

Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/video/saa7134/saa7134-input.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/saa7134/saa7134-input.c 
b/drivers/media/video/saa7134/saa7134-input.c
index ff6c0e9..d4ee24b 100644
--- a/drivers/media/video/saa7134/saa7134-input.c
+++ b/drivers/media/video/saa7134/saa7134-input.c
@@ -963,7 +963,7 @@ static int saa7134_raw_decode_irq(struct saa7134_dev *dev)
 * to work with other protocols.
 */
if (!ir-active) {
-   timeout = jiffies + jiffies_to_msecs(15);
+   timeout = jiffies + msecs_to_jiffies(15);
mod_timer(ir-timer, timeout);
ir-active = true;
}
-- 
1.7.1

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


RTL2831U driver updates

2011-06-16 Thread Jan Hoogenraad

Sascha: Thanks for the links

Would you know how to contact poma ?
http://www.spinics.net/lists/linux-media/msg24890.html

I will be getting more info from Realtek soon.
I did not realize that they were putting out updated drivers.

Once the status becomes more clear, I'll update
http://www.linuxtv.org/wiki/index.php/Realtek_RTL2831U

Sascha Wüstemann wrote:

Thomas Holzeisen wrote:

Hi there,

I tried to get an RTL2831U dvb-t usb-stick running with a more recent kernel 
(2.6.38) and failed.

The hg respository ~jhoogenraad/rtl2831-r2 aborts on countless drivers, the rc 
coding seem have to
changed a lot since it got touched the last time.

The hg respository ~anttip/rtl2831u wont compile as well, since its even older.

The recent git respositories for media_tree and anttip dont contain drivers for 
the rtl2831u.

Has this device been abandoned, or is anyone working on it?

greetings,
Thomas


There are still people working on it and there is new sources, e.g. look at
http://www.spinics.net/lists/linux-media/msg24890.html
at the very bottom. Worked like a charm at my system with kernel 2.6.39.

I think, there will be announcements later at
http://wiki.zeratul.org/doku.php?id=linux:v4l:realtek:start

Greetings from Braunschweig, Germany.
Sascha
--
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




--
Jan Hoogenraad
Hoogenraad Interface Services
Postbus 2717
3500 GS Utrecht
--
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 2/8] marvell-cam: Separate out the Marvell camera core

2011-06-16 Thread Mauro Carvalho Chehab
Em 15-06-2011 23:30, Kassey Lee escreveu:
 2011/6/14 Jonathan Corbet cor...@lwn.net:
 On Tue, 14 Jun 2011 10:58:47 +0800
 Kassey Lee kassey1...@gmail.com wrote:
 +   /*
 +* Try to find the sensor.
 +*/
 +   cam-sensor_addr = ov7670_info.addr;
 +   cam-sensor = v4l2_i2c_new_subdev_board(cam-v4l2_dev,
 +   cam-i2c_adapter, ov7670_info, NULL);
 I do not thinks so.

 I don't understand what this comment is meant to mean...?
 this should be move out to arch/arm/mach-xxx/board.c

Please drop the parts that you're not commenting. It is very hard to find a 
one-line
comment in the middle of a long patch, especially since you don't even add blank
lines before/after it.

With respect to your comment, it doesn't makes much sense,as cafe_ccic 
runs on OLPC 1 hardware (at least the version I have here) is x86-based.

So, I'm not seeing any reason why not apply patch 2/8.

Applying on my tree.

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


Re: [PATCH 2/8] marvell-cam: Separate out the Marvell camera core

2011-06-16 Thread Mauro Carvalho Chehab
Em 16-06-2011 12:27, Jonathan Corbet escreveu:
 On Thu, 16 Jun 2011 11:12:03 +0800
 Kassey Lee kassey1...@gmail.com wrote:
 
   2) for mcam_ctlr_stop_dma implementation, I guess you know
 something about the silicon limitation,  but we found it can not pass
 our stress test(1000 times capture test, which will switch format
 between JPEG and YUV again and again).
our solution is :
stop the ccic controller and wait for about one frame transfer
 time, and the stop the sensor.
this passed our stress test. for your info.
 
 Actually, I know very little that's not in the datasheet.  Are you telling
 me that there are hardware limitations that aren't documented, and that
 the datasheet is not a 100% accurate description of what's going on?  I'm
 *shocked* I tell you!
 
 (For the record, with both Cafe and Armada 610, I've found the hardware to
 be more reasonable and in accord with the documentation than with many
 others.)
 
 In any case, I don't know about the limitation you're talking about here,
 could you elaborate a bit?  For stress testing I've run video capture for
 weeks at a time, so obviously you're talking about something else.  Sounds
 like something I need to know?
 
3) for videoubuf2, will you use videoubuf2 only or combined
 with soc-camera ? when can your driver for videoubuf2 ready ?
 
 Videobuf2 only.  To be honest, I've never quite understood what soc-camera
 buys.  If there's a reason to do a switch, it could be contemplated - but
 remember that Cafe is not an SoC device.
 
 The vb2 driver is working now in vmalloc mode, which is probably what Cafe
 will need forever.  I do plan to add dma-contig, and, probably, dma-sg
 support in the very near future.  If you want, I can post the vmalloc
 version later today; I just want to make one more pass over it first.
 
4) the point is: ccic and sensor driver should be independent,
 and support two CCIC controller.
 
 No disagreement there.  I believe that two controllers should work now -
 though there's probably a gotcha somewhere since it's not actually been
 tried.  

Well, I'll be applying the patch series, as the above seems to be
points for future improvements, and don't seem to prevent the
addition of this patch series.

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


Re: [PATCH 6/8] marvell-cam: Right-shift i2c slave ID's in the cafe driver

2011-06-16 Thread Mauro Carvalho Chehab
Em 11-06-2011 14:46, Jonathan Corbet escreveu:
 This makes the cafe i2c implement consistent with the rest of Linux so that
 the core can use the same slave ID everywhere.
 
 Signed-off-by: Jonathan Corbet cor...@lwn.net
 ---
  drivers/media/video/marvell-ccic/cafe-driver.c |9 -
  drivers/media/video/marvell-ccic/mcam-core.c   |2 +-
  2 files changed, 9 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/media/video/marvell-ccic/cafe-driver.c 
 b/drivers/media/video/marvell-ccic/cafe-driver.c
 index 1027265..3dbc7e5 100644
 --- a/drivers/media/video/marvell-ccic/cafe-driver.c
 +++ b/drivers/media/video/marvell-ccic/cafe-driver.c
 @@ -84,7 +84,14 @@ struct cafe_camera {
  #defineTWSIC0_EN   0x0001/* TWSI enable */
  #defineTWSIC0_MODE 0x0002/* 1 = 16-bit, 0 = 8-bit */
  #defineTWSIC0_SID  0x03fc/* Slave ID */
 -#defineTWSIC0_SID_SHIFT 2
 +/*
 + * Subtle trickery: the slave ID field starts with bit 2.  But the
 + * Linux i2c stack wants to treat the bottommost bit as a separate
 + * read/write bit, which is why slave ID's are usually presented
 + * 1.  For consistency with that behavior, we shift over three
 + * bits instead of two.
 + */

And this is consistent with the initial Philips I2C datasheets ;) Newer 
datasheets
use to include the read/write bit as if they're part of the I2C address, as 
well as
the registers that command I2C operations inside most chipsets. So, we end
by having 7-bit and 8-bit notations for I2C addresses.

 +#defineTWSIC0_SID_SHIFT 3
  #defineTWSIC0_CLKDIV   0x0007fc00/* Clock divider */
  #defineTWSIC0_MASKACK  0x0040/* Mask ack from sensor */
  #defineTWSIC0_OVMAGIC  0x0080/* Make it work on OV sensors */
 diff --git a/drivers/media/video/marvell-ccic/mcam-core.c 
 b/drivers/media/video/marvell-ccic/mcam-core.c
 index 0d60234..d5f18a3 100644
 --- a/drivers/media/video/marvell-ccic/mcam-core.c
 +++ b/drivers/media/video/marvell-ccic/mcam-core.c
 @@ -1549,7 +1549,7 @@ int mccic_register(struct mcam_camera *cam)
  {
   struct i2c_board_info ov7670_info = {
   .type = ov7670,
 - .addr = 0x42,
 + .addr = 0x42  1,
   .platform_data = sensor_cfg,
   };
   int ret;

Patch is OK.

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


Re: [PATCH 8/8] marvell-cam: Basic working MMP camera driver

2011-06-16 Thread Mauro Carvalho Chehab
Em 16-06-2011 16:44, Sylwester Nawrocki escreveu:
 Hello,
 
 On 06/16/2011 05:17 PM, Jonathan Corbet wrote:
 On Thu, 16 Jun 2011 10:37:37 +0800
 Kassey Leekassey1...@gmail.com  wrote:

 +static void mmpcam_power_down(struct mcam_camera *mcam)
 +{
 +   struct mmp_camera *cam = mcam_to_cam(mcam);
 +   struct mmp_camera_platform_data *pdata;
 +/*
 + * Turn off clocks and set reset lines
 + */
 +   iowrite32(0, cam-power_regs + REG_CCIC_DCGCR);
 +   iowrite32(0, cam-power_regs + REG_CCIC_CRCR);
 +/*
 + * Shut down the sensor.
 + */
 +   pdata = cam-pdev-dev.platform_data;
 +   gpio_set_value(pdata-sensor_power_gpio, 0);
 +   gpio_set_value(pdata-sensor_reset_gpio, 0);

 it is better to have a callback function to controller sensor power on/off.
 and place the callback function in board.c
 
 It might be more convenient for the driver writer but I do not think
 it is generally better. Platform callbacks cannot really be migrated 
 to FDT. For reasons pointed out by Jon below I have also been trying
 to avoid callbacks in sensors' platform data.

Well, outside the SoC world, we use two different approaches for GPIO:

The first and more used one is to add the GPIO settings into a per-card model
table (see the tables at cx88-cards, em28xx-cards, etc). Once the driver
detects what's the card model (by USB ID or PCI ID), it selects one
line at the board table entry. This works better than callbacks, and are
very simple to code.

Unfortunately, on a few cases, the GPIO's need to be set during a subdev
operation, on several tuners, like the Xceive family of tuners, that require
a chip reset via GPIO during firmware load.


 This is an interesting question, actually.  The problem is that board
 files are on their way out; it's going to be very hard to get any more
 board files into the mainline going forward.

 The mmp-camera driver does depend on a board file, but I've been careful
 to restrict things to basic platform data which can just as easily be put
 into a device tree.  Power management callbacks don't really qualify.

 So it seems that we need to figure out a way to push this kind of
 pin/power management down into the sensor-specific code.  Looking at the
 subdev stuff, it looks like a bit of thought has been put into that
 direction; there's the s_io_pin_config() callback to describe pins to the
 
 But having sensor's GPIOs configured by bridge driver does not help us
 much here, does it? The bridge driver would still need to retrieve the
 sensor configuration from somewhere, since it is machine/board specific.
 And it's the subdev driver that will know how the GPIOs should be handled,
 the timing constraints, etc. So as long as we can pass gpio numbers from
 a device tree to subdevs we probably do not need an additional subdev 
 operation. 
 I guess when there come more subdev drivers dealing with GPIOs we could try
 and see what could be generalized.

On my experiences, the timings and even the meanings for GPIO's are not subdev
specific, at least outside SoC world. Especially when you have multiple devices
sharing the same I2C bus, timings need to be adjusted to avoid troubles with
other chips, and due to capacitance effects at the board tracks.

 
 sensor.  But it's almost entirely unused.

 There is no power up/down callback, currently.  We could ponder on
 
 We have the subdev s_power core operation in struct v4l2_subdev_core_ops.
 However it seems that its semantic is not yet clearly documented.

Yes, s_power is meant to be used for putting a sub-device to sleep or for
waking it up.

 whether one should be added, or whether this should be handled through the
 existing power management code somehow.  I honestly don't know what the
 best answer is on this one - will have to do some digging.  Suggestions
 welcome.
 
 --
 Regards,
 Sylwester
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

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


Re: [PATCH 2/8] marvell-cam: Separate out the Marvell camera core

2011-06-16 Thread Kassey Lee
2011/6/17 Mauro Carvalho Chehab mche...@infradead.org:
 Em 15-06-2011 23:30, Kassey Lee escreveu:
 2011/6/14 Jonathan Corbet cor...@lwn.net:
 On Tue, 14 Jun 2011 10:58:47 +0800
 Kassey Lee kassey1...@gmail.com wrote:
 +       /*
 +        * Try to find the sensor.
 +        */
 +       cam-sensor_addr = ov7670_info.addr;
 +       cam-sensor = v4l2_i2c_new_subdev_board(cam-v4l2_dev,
 +                       cam-i2c_adapter, ov7670_info, NULL);
 I do not thinks so.

 I don't understand what this comment is meant to mean...?
 this should be move out to arch/arm/mach-xxx/board.c

 Please drop the parts that you're not commenting. It is very hard to find a 
 one-line
 comment in the middle of a long patch, especially since you don't even add 
 blank
 lines before/after it.

sorry for the confusion.
this is the same idea that we want to separate the ccic driver and sensor info.
here is how we do this:
on arch/arm/mach-mmp/ttc_dkb.c

static struct i2c_board_info dkb_i2c_camera[] = {
{
I2C_BOARD_INFO(ov5642, 0x3c),
},
};

i2c_register_board_info(0, dkb_i2c_camera, 1);


 With respect to your comment, it doesn't makes much sense,as cafe_ccic
 runs on OLPC 1 hardware (at least the version I have here) is x86-based.

 that is fine, sorry, i always thought it was ARM platform.

 So, I'm not seeing any reason why not apply patch 2/8.

 Applying on my tree.

 Mauro.





-- 
Best regards
Kassey
Application Processor Systems Engineering, Marvell Technology Group Ltd.
Shanghai, China.
--
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 2/8] marvell-cam: Separate out the Marvell camera core

2011-06-16 Thread Kassey Lee
2011/6/16 Jonathan Corbet cor...@lwn.net:
 On Thu, 16 Jun 2011 11:12:03 +0800
 Kassey Lee kassey1...@gmail.com wrote:

       2) for mcam_ctlr_stop_dma implementation, I guess you know
 something about the silicon limitation,  but we found it can not pass
 our stress test(1000 times capture test, which will switch format
 between JPEG and YUV again and again).
        our solution is :
        stop the ccic controller and wait for about one frame transfer
 time, and the stop the sensor.
        this passed our stress test. for your info.

 Actually, I know very little that's not in the datasheet.  Are you telling
 me that there are hardware limitations that aren't documented, and that
 the datasheet is not a 100% accurate description of what's going on?  I'm
 *shocked* I tell you!

 (For the record, with both Cafe and Armada 610, I've found the hardware to
 be more reasonable and in accord with the documentation than with many
 others.)

 In any case, I don't know about the limitation you're talking about here,
 could you elaborate a bit?  For stress testing I've run video capture for
 weeks at a time, so obviously you're talking about something else.  Sounds
 like something I need to know?
hi, Jon:
 the problem is:
 when we stop CCIC, and then switch to another format.
 at this stage, actually, CCIC DMA is not stopped until the
transferring frame is done. this will cause system hang if we start
CCIC again with another format.
 we've ask silicon design to add CCIC DMA stop/start controller bit.

 from your logic, when stop DMA, you are test the EOF/SOF, so I
wonder why you want to do this ?
 and is your test will stop CCIC and start CCIC frequently  ?
 thanks

        3) for videoubuf2, will you use videoubuf2 only or combined
 with soc-camera ? when can your driver for videoubuf2 ready ?

 Videobuf2 only.  To be honest, I've never quite understood what soc-camera
 buys.  If there's a reason to do a switch, it could be contemplated - but
 remember that Cafe is not an SoC device.

 The vb2 driver is working now in vmalloc mode, which is probably what Cafe
 will need forever.  I do plan to add dma-contig, and, probably, dma-sg
 support in the very near future.  If you want, I can post the vmalloc
 version later today; I just want to make one more pass over it first.

could you please share the vmalloc way to me ?
and if the dma-contig is OK, I'm glad to verify on our platform.
as to test USERPTR, we are using a PMEM to get phy-contig memory in
user space, and then QBUF to driver.

        4) the point is: ccic and sensor driver should be independent,
 and support two CCIC controller.

 No disagreement there.  I believe that two controllers should work now -
 though there's probably a gotcha somewhere since it's not actually been
 tried.

 Thanks,

 jon




-- 
Best regards
Kassey
Application Processor Systems Engineering, Marvell Technology Group Ltd.
Shanghai, China.
--
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