Re: [PATCH] dma-buf: document fd flags and O_CLOEXEC requirement

[Sumit Semwal]

On 20 March 2012 03:12, Rob Clark  wrote:
> From: Rob Clark 
>
> Otherwise subsystems will get this wrong and end up with a second
> export ioctl with the flag and O_CLOEXEC support added.
>
> Signed-off-by: Rob Clark 
> Reviewed-by: Daniel Vetter 
> ---
> Updated version of Daniel's original documentation patch with (hopefully)
> improved wording, and a better description of the motivation.
Thanks; applied this in place of Daniel's to for-next.
>
BR,
~Sumit.
--
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 3/4] dma_buf: Add documentation for the new cpu access support

[Sumit Semwal]

On 19 March 2012 07:24, Rob Clark  wrote:
> On Sun, Mar 18, 2012 at 6:34 PM, Daniel Vetter  wrote:
>> v2: Fix spelling issues noticed by Rob Clark.
>>
>> Signed-off-by: Daniel Vetter 
>
> Signed-off-by: Rob Clark 
Thanks; applied to for-next.
>

BR,
~me.
--
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] dma-buf: add support for kernel cpu access

[Sumit Semwal]

On 20 March 2012 04:32, Daniel Vetter  wrote:
> Big differences to other contenders in the field (like ion) is
> that this also supports highmem, so we have to split up the cpu
> access from the kernel side into a prepare and a kmap step.
>
> Prepare is allowed to fail and should do everything required so that
> the kmap calls can succeed (like swapin/backing storage allocation,
> flushing, ...).
>
> More in-depth explanations will follow in the follow-up documentation
> patch.
>
> Changes in v2:
>
> - Clear up begin_cpu_access confusion noticed by Sumit Semwal.
> - Don't automatically fallback from the _atomic variants to the
>  non-atomic variants. The _atomic callbacks are not allowed to
>  sleep, so we want exporters to make this decision explicit. The
>  function signatures are explicit, so simpler exporters can still
>  use the same function for both.
> - Make the unmap functions optional. Simpler exporters with permanent
>  mappings don't need to do anything at unmap time.
>
> Changes in v3:
>
> - Adjust the WARN_ON checks for the new ->ops functions as suggested
>  by Rob Clark and Sumit Semwal.
> - Rebased on top of latest dma-buf-next git.
>
> Changes in v4:
>
> - Fixup a missing - in a return -EINVAL; statement.
>
> Signed-Off-by: Daniel Vetter 
Thanks; applied to for-next.
> ---

BR,
~Sumit.
--
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 1/4] dma-buf: don't hold the mutex around map/unmap calls

[Sumit Semwal]

On 19 March 2012 05:04, Daniel Vetter  wrote:
> The mutex protects the attachment list and hence needs to be held
> around the callbakc to the exporters (optional) attach/detach
> functions.
>
> Holding the mutex around the map/unmap calls doesn't protect any
> dma_buf state. Exporters need to properly protect any of their own
> state anyway (to protect against calls from their own interfaces).
> So this only makes the locking messier (and lockdep easier to anger).
>
> Therefore let's just drop this.
>
> v2: Rebased on top of latest dma-buf-next git.
>
> Signed-off-by: Daniel Vetter 
> Reviewed-by: Rob Clark 
Thanks; Applied to for-next.
> ---

BR,
~Sumit.
--
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] usb: gadget/uvc: Remove non-required locking from 'uvc_queue_next_buffer' routine

[Bhupesh Sharma]

This patch removes the non-required spinlock acquire/release calls on
'queue_irqlock' from 'uvc_queue_next_buffer' routine.

This routine is called from 'video->encode' function (which translates to either
'uvc_video_encode_bulk' or 'uvc_video_encode_isoc') in 'uvc_video.c'.
As, the 'video->encode' routines are called with 'queue_irqlock' already held,
so acquiring a 'queue_irqlock' again in 'uvc_queue_next_buffer' routine causes
a spin lock recursion.

Signed-off-by: Bhupesh Sharma 
Acked-by: Laurent Pinchart 
---
 drivers/usb/gadget/uvc_queue.c |4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/gadget/uvc_queue.c b/drivers/usb/gadget/uvc_queue.c
index d776adb..104ae9c 100644
--- a/drivers/usb/gadget/uvc_queue.c
+++ b/drivers/usb/gadget/uvc_queue.c
@@ -543,11 +543,11 @@ done:
return ret;
 }
 
+/* called with &queue_irqlock held.. */
 static struct uvc_buffer *
 uvc_queue_next_buffer(struct uvc_video_queue *queue, struct uvc_buffer *buf)
 {
struct uvc_buffer *nextbuf;
-   unsigned long flags;
 
if ((queue->flags & UVC_QUEUE_DROP_INCOMPLETE) &&
buf->buf.length != buf->buf.bytesused) {
@@ -556,14 +556,12 @@ uvc_queue_next_buffer(struct uvc_video_queue *queue, 
struct uvc_buffer *buf)
return buf;
}
 
-   spin_lock_irqsave(&queue->irqlock, flags);
list_del(&buf->queue);
if (!list_empty(&queue->irqqueue))
nextbuf = list_first_entry(&queue->irqqueue, struct uvc_buffer,
   queue);
else
nextbuf = NULL;
-   spin_unlock_irqrestore(&queue->irqlock, flags);
 
buf->buf.sequence = queue->sequence++;
do_gettimeofday(&buf->buf.timestamp);
-- 
1.7.2.2

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

Re: [PATCH v2 1/1] media: video: s5p-g2d: Add support for FIMG2D v41 H/W logic

[Ajay kumar]

Hi Mr.Sakari

On Sun, Mar 18, 2012 at 12:27 AM, Sakari Ailus  wrote:
> Hi Ajay,
>
> Thanks for the patch. I have a few comments below.
>
> On Sat, Mar 17, 2012 at 04:52:14PM +0530, Ajay Kumar wrote:
>> Modify the G2D driver(which initially supported only FIMG2D v3 style H/W)
>> to support FIMG2D v41 style hardware present on Exynos4x12 and Exynos52x0 
>> SOC.
>>
>>       -- Set the SRC and DST type to 'memory' instead of using reset values.
>>       -- FIMG2D v41 H/W uses different logic for stretching(scaling).
>>       -- Use CACHECTL_REG only with FIMG2D v3.
>>
>> Signed-off-by: Ajay Kumar 
>> ---
>>  drivers/media/video/s5p-g2d/g2d-hw.c   |   39 
>> ---
>>  drivers/media/video/s5p-g2d/g2d-regs.h |    6 +
>>  drivers/media/video/s5p-g2d/g2d.c      |   23 +-
>>  drivers/media/video/s5p-g2d/g2d.h      |    9 ++-
>>  4 files changed, 70 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/media/video/s5p-g2d/g2d-hw.c 
>> b/drivers/media/video/s5p-g2d/g2d-hw.c
>> index 5b86cbe..f8225b8 100644
>> --- a/drivers/media/video/s5p-g2d/g2d-hw.c
>> +++ b/drivers/media/video/s5p-g2d/g2d-hw.c
>> @@ -28,6 +28,8 @@ void g2d_set_src_size(struct g2d_dev *d, struct g2d_frame 
>> *f)
>>  {
>>       u32 n;
>>
>> +     w(0, SRC_SELECT_REG);
>> +
>>       w(f->stride & 0x, SRC_STRIDE_REG);
>>
>>       n = f->o_height & 0xFFF;
>> @@ -52,6 +54,8 @@ void g2d_set_dst_size(struct g2d_dev *d, struct g2d_frame 
>> *f)
>>  {
>>       u32 n;
>>
>> +     w(0, DST_SELECT_REG);
>> +
>>       w(f->stride & 0x, DST_STRIDE_REG);
>>
>>       n = f->o_height & 0xFFF;
>> @@ -82,10 +86,36 @@ void g2d_set_flip(struct g2d_dev *d, u32 r)
>>       w(r, SRC_MSK_DIRECT_REG);
>>  }
>>
>> -u32 g2d_cmd_stretch(u32 e)
>> +/**
>> + * g2d_calc_scale_factor - convert scale factor to fixed pint 16
>
> Point, perhaps?
Ok. Typo.

>> + * @n: numerator
>> + * @d: denominator
>> + */
>> +static unsigned long g2d_calc_scale_factor(int n, int d)
>> +{
>> +     return (n << 16) / d;
>> +}
>> +
>> +void g2d_set_v41_stretch(struct g2d_dev *d, struct g2d_frame *src,
>> +                                     struct g2d_frame *dst)
>>  {
>> -     e &= 1;
>> -     return e << 4;
>> +     int src_w, src_h, dst_w, dst_h;
>
> Is int intentional --- width and height usually can't be negative.
I will use 'unsigned int'.

>> +     u32 wcfg, hcfg;
>> +
>> +     w(DEFAULT_SCALE_MODE, SRC_SCALE_CTRL_REG);
>> +
>> +     src_w = src->c_width;
>> +     src_h = src->c_height;
>> +
>> +     dst_w = dst->c_width;
>> +     dst_h = dst->c_height;
>> +
>> +     /* inversed scaling factor: src is numerator */
>> +     wcfg = g2d_calc_scale_factor(src_w, dst_w);
>> +     hcfg = g2d_calc_scale_factor(src_h, dst_h);
>
> I think this would be more simple without that many temporary variables and
> an extra function.
You are right. I will Change it.

>> +     w(wcfg, SRC_XSCALE_REG);
>> +     w(hcfg, SRC_YSCALE_REG);
>>  }
>>
>>  void g2d_set_cmd(struct g2d_dev *d, u32 c)
>> @@ -96,7 +126,8 @@ void g2d_set_cmd(struct g2d_dev *d, u32 c)
>>  void g2d_start(struct g2d_dev *d)
>>  {
>>       /* Clear cache */
>> -     w(0x7, CACHECTL_REG);
>> +     if (d->device_type == TYPE_G2D_3X)
>> +             w(0x7, CACHECTL_REG);
>>       /* Enable interrupt */
>>       w(1, INTEN_REG);
>>       /* Start G2D engine */
>
> Kind regards,
>
> --
> Sakari Ailus
> e-mail: sakari.ai...@iki.fi     jabber/XMPP/Gmail: sai...@retiisi.org.uk
> --
> 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

Thanks for your review and comments. I will resubmit the patch with changes.

Regards,
Ajay
--
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] [RFC] dma-buf: mmap support

[Daniel Vetter]

On Wed, Mar 21, 2012 at 03:44:38PM -0700, Rebecca Schultz Zavin wrote:
> Couldn't this just as easily be handled by not having those mappings
> be mapped cached or write combine to userspace?  They'd be coherent,
> just slow.  I'm not sure we can actually say that all these cpu access
> are necessary slow path operations anyway.  On android we do sometimes
> decide to software render things to eliminate the overhead of
> maintaining a hardware context for context switching the gpu.   If you
> want cached or writecombine mappings you'd have to manage them
> explicitly.  If you can't manage them explicitly you have to settle
> for slow.  That seems reasonable to me.

Well the usual approach is writecombine, which doesn't need any explicit
cache management. 

> As far as I can tell with explicit operations I have to invalidate
> before touching from mmap and clean after.  With these implicit ones,
> I stil have to invalidate and clean, but now I also have to remap them
> before and after.  I don't know what the performance hit of this
> remapping step is, but I'd like to if you have any insight.

We have a few inefficiencies in the drm/i915 fault path which makes it
slow, but generally pagefault performance should be rather quick (at least
quicker than flushing the actual data). At least if your fault handler is
somewhat clever and prefaults a few more pages in both x and y direction.

But if that's too slow, I'm open to extending dma-buf later on to support
more explicit cache management for userspace mmaps (like I've explained
below in my previous mail). I just think we should have real benchmark
results (and hence some real users of dma-buf) before we add this
complexity. Atm I have no idea whether it's worth it. After all, as soon
as we expect a lot of rendering/processing, some special dsp/gpu/whatever
is likely to take over.

> > Imo the best way to enable cached mappings is to later on extend dma-buf
> > (as soon as we have some actual exporters/importers in the mainline
> > kernel) with an optional cached_mmap interface which requires explict
> > prepare_mmap_access/finish_mmap_acces calls. Then if both exporter and
> > importer support this, it could get used - otherwise the dma-buf layer
> > could transparently fall back to coherent mappings.

Yours, Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
--
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] [RFC] dma-buf: mmap support

[Rebecca Schultz Zavin]

On Wed, Mar 21, 2012 at 3:25 PM, Daniel Vetter  wrote:
> On Wed, Mar 21, 2012 at 10:46:14AM -0700, Rebecca Schultz Zavin wrote:
>> I want to make sure I understand how this would work.  I've been planning
>> on making cache maintenance implicit, and most of the corresponding
>> userspace components I've seen for android expect to do implicit cache
>> maintenance on these buffers if they need cached mappings.  The android
>> framework has a logical place for this maintenance to take place.  I assume
>> that you'd detect a buffer leaving the cpu domain by using the
>> dma_data_direction passed to dma_buf_map_attachment?  We're definitely
>> pushing a bunch of complexity into the exporter, that at least on android
>> could easily be covered by an explicit api.  I'm not dead set against it, I
>> just want to make sure I get it right if we go down this road.
>
> Hm, you're talking about implicit cache management, which I read as: The
> kernel does some magic so that userspace doesn't have to care. But I guess
> you mean what I'd call explicit cache management, where userspace tells
> the kernel which ranges to invalidate/flush?

Sorry, yeah, I got that backwards :)  I definitely mean that I
intended to do all the cache maintenance explicitly.

>
> The idea is that the exporter would invalidate cpu caches at fault time.
> And when a dma-device wants to read from it (using the direction argument
> of dma_buf_map_attachement) it would shoot down the mappings, flush caches
> and then allow the dma op to happen. Note that this is obvously only
> required if the mapping is not coherent (uc/wc on arm).

This makes sense to me though I have to sort thought exactly how to
implement it.

>
> I agree that for cached mappings this will suck, but to get dma-buf of the
> ground I prefer a simpler interface at the beginning, which could get
> extended later on. The issue is that I expect that a few importers simply
> can't hanlde cache management with explicit flush/invalidate ioctl calls
> from userspace and we hence need coherently-looking mappings anyway.

Couldn't this just as easily be handled by not having those mappings
be mapped cached or write combine to userspace?  They'd be coherent,
just slow.  I'm not sure we can actually say that all these cpu access
are necessary slow path operations anyway.  On android we do sometimes
decide to software render things to eliminate the overhead of
maintaining a hardware context for context switching the gpu.   If you
want cached or writecombine mappings you'd have to manage them
explicitly.  If you can't manage them explicitly you have to settle
for slow.  That seems reasonable to me.

As far as I can tell with explicit operations I have to invalidate
before touching from mmap and clean after.  With these implicit ones,
I stil have to invalidate and clean, but now I also have to remap them
before and after.  I don't know what the performance hit of this
remapping step is, but I'd like to if you have any insight.

Rebecca

>
> Imo the best way to enable cached mappings is to later on extend dma-buf
> (as soon as we have some actual exporters/importers in the mainline
> kernel) with an optional cached_mmap interface which requires explict
> prepare_mmap_access/finish_mmap_acces calls. Then if both exporter and
> importer support this, it could get used - otherwise the dma-buf layer
> could transparently fall back to coherent mappings.
>
> Cheers, Daniel
> --
> Daniel Vetter
> Mail: dan...@ffwll.ch
> Mobile: +41 (0)79 365 57 48
--
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] [RFC] dma-buf: mmap support

[Daniel Vetter]

On Wed, Mar 21, 2012 at 10:46:14AM -0700, Rebecca Schultz Zavin wrote:
> I want to make sure I understand how this would work.  I've been planning
> on making cache maintenance implicit, and most of the corresponding
> userspace components I've seen for android expect to do implicit cache
> maintenance on these buffers if they need cached mappings.  The android
> framework has a logical place for this maintenance to take place.  I assume
> that you'd detect a buffer leaving the cpu domain by using the
> dma_data_direction passed to dma_buf_map_attachment?  We're definitely
> pushing a bunch of complexity into the exporter, that at least on android
> could easily be covered by an explicit api.  I'm not dead set against it, I
> just want to make sure I get it right if we go down this road.

Hm, you're talking about implicit cache management, which I read as: The
kernel does some magic so that userspace doesn't have to care. But I guess
you mean what I'd call explicit cache management, where userspace tells
the kernel which ranges to invalidate/flush?

The idea is that the exporter would invalidate cpu caches at fault time.
And when a dma-device wants to read from it (using the direction argument
of dma_buf_map_attachement) it would shoot down the mappings, flush caches
and then allow the dma op to happen. Note that this is obvously only
required if the mapping is not coherent (uc/wc on arm).

I agree that for cached mappings this will suck, but to get dma-buf of the
ground I prefer a simpler interface at the beginning, which could get
extended later on. The issue is that I expect that a few importers simply
can't hanlde cache management with explicit flush/invalidate ioctl calls
from userspace and we hence need coherently-looking mappings anyway.

Imo the best way to enable cached mappings is to later on extend dma-buf
(as soon as we have some actual exporters/importers in the mainline
kernel) with an optional cached_mmap interface which requires explict
prepare_mmap_access/finish_mmap_acces calls. Then if both exporter and
importer support this, it could get used - otherwise the dma-buf layer
could transparently fall back to coherent mappings.

Cheers, Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
--
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: Move em27xx/em28xx webcams to a gspca subdriver ?

[Mauro Carvalho Chehab]

Em 21-03-2012 15:01, Frank Schäfer escreveu:
> Am 16.03.2012 23:18, schrieb Frank Schäfer:
>> [Was: eMPIA EM2710 Webcam (em28xx) and LIRC]
>>
>> Continue this part of the discussion in a new thread...
>>
>> Am 15.03.2012 14:05, schrieb Mauro Carvalho Chehab:
>>> Em 15-03-2012 09:34, Frank Schäfer escreveu:
 ...

 I would like to bring up the question, if it wouldn't make sense to move
 support for the em27xx/28xx webcams to a separate gspca-subdriver.
>>> The em2710/2750 chips are very similar to em2820. There's not much sense
>>> on moving it elsewhere, as it would duplicate a lot of the existing code,
>>> for no good reason.
>> Yes, that was my first thought, too.
>> But looking at the resulting gspca subdriver, you will see that there is
>> not much code duplication.
>> I would say that adding support for this device as a gspca subdriver
>> requires less new lines of code than extending/modifying the em28xx driver.
>>
 I'm currently working on adding support for the VAD Laplace webcam
 (em2765 + OV2640) (http://linuxtv.org/wiki/index.php/VAD_Laplace).
 Lots of modifications to the em28xx driver would be necessary to support
 this device because of some significant differences:
 - supports only bulk transfers
>>> em28xx supports it as well, but it is used only for dvb, currently.
>> You are talking about the em28xx device capabilities, right ?
>> AFAIK, the em28xx driver still has no bulk transfer support.
>>
 - uses proprietary I2C-writes
>>> huh? I2C writes are proprietary. What do you mean?
>> Maybe proprietary is not the best name...
>> Requests 0x06 an 0x08 are used for the usb control messages.
>> I have documented that at http://linuxtv.org/wiki/index.php/VAD_Laplace.
>> Could be the "vendor specific" usb requests the datasheet talks about.
>>
 - em25xx-eeprom
>>> Are you meaning more than 256 addresses eeprom? Newer Empia chips use it,
>>> not only the webcam ones. Currently, the code detects it but nobody wrote
>>> an implementation for it yet. It would likely make sense to implement it
>>> at em28xx anyway.
>> Yes, the device has an eeprom with 16bit addresses.
>> Anyway, I'm talking about a different format of the eeprom data:
>> http://wenku.baidu.com/view/a21a28eab8f67c1cfad6b8f6.html
>>
>> You can find the eeprom content of my device at
>> http://linuxtv.org/wiki/index.php/VAD_Laplace
>>
 - ov2640 sensor
>>> The better is to use a separate I2C driver for the sensor. This is not
>>> a common practice at gspca, but doing that would help to re-use the sensor
>>> driver elsewhere.
>> I agree. But let's do things step by step...
>>
 Lots of changes concerning the USB-interface probing, button handling,
 video controls, frame processing and more would be necessary, too.
>>> Video controls are implemented at the sensor sub-driver, so this is not
>>> an issue.
>>>
>>> Anyway, if em2765 is different enough from em2874 and em2750, then it makes
>>> sense to write it as a separate driver. Otherwise, it is better to add 
>>> support
>>> for it there.
>> No, the em2765 itself seems to be very similar to the other
>> em27xx/em28xx chips.
>> But the device as a whole is different enough to consider a separate driver.
>>
 For reverse engineering purposes, I decided to write a gspca subdriver
 for this device (will send a patch for testing/discussion soon).
>>> Ok.
>> See the patch posted a minute ago.
>>
 I have no strong opinion about this, but I somehow feel that the em28xx
 driver gets bloated more and more...
>>> The advantage of adding it there is that it generally reduces maintenance 
>>> efforts, as the same code and fixes don't need to be added on two separate
>>> places.
>> Yes, that's right. But on the other hand, the benefit of separate
>> drivers is simpler code, which is easier to maintain/understand.
>> For example, there would be no LIRC modules issue ;-)
>>
>>> For example, if the em2765 eeprom access is similar to em2874, the same
>>> code chunk would be required on both drivers.
>> Sure, code duplication is one of the disadvantages. The question is how
>> much duplicate code there would be.
>>
>> Regards,
>> Frank
>>
>>> Regards,
>>> Mauro
> Ping !
> No comments, opinions ? ;-)

-ETOOBUSY ;)

We're in the middle of a merge window. I don't have any time
during this and the next week for discussing it due to that,
as there are some maintainer's task that I need to handle.

Please ping me by the beginning of April, after the end of the
merge window.

Sorry,
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 1/2] [media] dib0700: Drop useless check when remote key is pressed

[Jean Delvare]

Hi Mauro,

On Tue, 20 Mar 2012 09:17:54 -0300, Mauro Carvalho Chehab wrote:
> Em 20-03-2012 04:20, Jean Delvare escreveu:
> > On Mon, 19 Mar 2012 19:26:11 -0300, Mauro Carvalho Chehab wrote:
> >> Yet, I'd be more happy if Jean's patch could check first if the status is
> >> below 0, in order to prevent a possible race condition at device 
> >> disconnect.
> > 
> > I'm not sure I see the race condition you're seeing. Do you believe
> > purb->context would be NULL (or point to already-freed memory) when
> > dib0700_rc_urb_completion is called as part of device disconnect? Or is
> > it something else? I'll be happy to resubmit my patch series with a fix
> > if you explain where you think there is a race condition.
> 
> What I'm saying is that the only potential chance of having a NULL value
> for d is at the device disconnect/removal, if is there any bug when waiting
> for the URB's to be killed.
> 
> So, it would be better to invert the error test logic to:
> 
> static void dib0700_rc_urb_completion(struct urb *purb)
> {
>   struct dvb_usb_device *d = purb->context;
>   struct dib0700_rc_response *poll_reply;
>   u32 uninitialized_var(keycode);
>   u8 toggle;
> 
>   poll_reply = purb->transfer_buffer;
>   if (purb->status < 0) {
>   deb_info("discontinuing polling\n");
>   kfree(purb->transfer_buffer);
>   usb_free_urb(purb);
>   return;
>   }
> 
>   deb_info("%s()\n", __func__);
>   if (d->rc_dev == NULL) {
>   /* This will occur if disable_rc_polling=1 */
>   kfree(purb->transfer_buffer);
>   usb_free_urb(purb);
>   return;
>   }
> 
> As, at device disconnect/completion, the status will indicate an error, and
> the function will return before trying to de-referenciate rc_dev.

Hmm. I couldn't find any code that would reset purb->context. I tested
2000 rmmod dvb-usb-dib0700 on a 3.3.0 kernel with my two patches
applied, compiled with CONFIG_DEBUG_SLAB=y and CONFIG_DEBUG_VM=y, and
it did not crash nor report any problem. I don't think there is any
race here, so I see no point in changing the code. We just got rid of a
paranoid check, it is not to apply another paranoid patch.

-- 
Jean Delvare
--
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 1/2] Fitipower fc0011 driver

[Michael Büsch]

On Wed, 21 Mar 2012 20:12:03 +0100
Gianluca Gennari  wrote:

> > +#if 0 //TODO 3.3
> > +   struct dtv_frontend_properties *p = &fe->dtv_property_cache;
> > +   u32 freq = p->frequency / 1000;
> > +   u32 delsys = p->delivery_system;
> 
> The "delsys" variable is unused, you can delete it.

Thanks for your review. I fixed this.

-- 
Greetings, Michael.

PGP encryption is encouraged / 908D8B0E


signature.asc
Description: PGP signature

Problem with building linuxtv.org's V4L-DVB drivers

[Joe Henley]

I'm running kernel-ml-2.6.35-14.1.el5.elrepo

I'm following the info on:
http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers

First I run:
git clone git://linuxtv.org/media_build.git
cd media_build

Then when I run ./build, it stops with the following error:
 snip...
/root/media_build/v4l/radio-rtrack2.c: In function 'rtrack2_alloc':
/root/media_build/v4l/radio-rtrack2.c:46: error: implicit declaration of
function 'kzalloc'
/root/media_build/v4l/radio-rtrack2.c:46: warning: return makes pointer
from integer without a cast
make[3]: *** [/root/media_build/v4l/radio-rtrack2.o] Error 1
make[2]: *** [_module_/root/media_build/v4l] Error 2
make[1]: *** [default] Error 2
make: *** [all] Error 2
build failed at ./build line 410.

Hopefully this can fixed.

Joe Henley
--
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: [Q] v4l buffer format inside isoc

[Ezequiel García]

2012/3/21 Devin Heitmueller :
> I'm not sure what you mean by "no video".  Do you have capture
> disabled?  Are you saying that you didn't connect the video cable to
> your input?  Most devices will continue to generate video frames over
> isoc even if there is no actual video signal present.

I mean there is no signal at video input.

>
> But yeah, most of the solutions I have seen have every isoc packet
> starting with a header that includes descriptors for things like start
> of video frame, odd/even field, etc.
>

Thanks, I'll keep reading sources and info. Hope it gets me somewhere.
--
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: [Q] v4l buffer format inside isoc

[Devin Heitmueller]

2012/3/21 Ezequiel García :
> Ok. So, it's not saa7113 related, but rather stk1160 related?

Yes.

> When there is no video, isoc urbs are received with actual length=4.
> This is header right?

I'm not sure what you mean by "no video".  Do you have capture
disabled?  Are you saying that you didn't connect the video cable to
your input?  Most devices will continue to generate video frames over
isoc even if there is no actual video signal present.

But yeah, most of the solutions I have seen have every isoc packet
starting with a header that includes descriptors for things like start
of video frame, odd/even field, etc.

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 1/2] Fitipower fc0011 driver

[Gianluca Gennari]

Il 21/03/2012 16:56, Michael Büsch ha scritto:
> This adds the Fitipower fc0011 tuner driver.
> 
> Note: The '#if 0' statements will be removed on the final submission.
> 
> Signed-off-by: Michael Buesch 
> 
> ---

..

> +
> +#if 0 //TODO 3.3
> +static int fc0011_set_params(struct dvb_frontend *fe)
> +#else
> +static int fc0011_set_params(struct dvb_frontend *fe,
> +struct dvb_frontend_parameters *params)
> +#endif
> +{
> +struct fc0011_priv *priv = fe->tuner_priv;
> + int err;
> + unsigned int i;
> +#if 0 //TODO 3.3
> + struct dtv_frontend_properties *p = &fe->dtv_property_cache;
> + u32 freq = p->frequency / 1000;
> + u32 delsys = p->delivery_system;

The "delsys" variable is unused, you can delete it.

BTW, I only compiled the driver, as I don't have the hardware to test it.

Regards,
Gianluca


> + u32 bandwidth = p->bandwidth_hz / 1000;
> +#else
> + u32 freq = params->frequency / 1000;
> + u32 bandwidth = params->u.ofdm.bandwidth / 1000;
> +#endif
--
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: [Q] v4l buffer format inside isoc

[Ezequiel García]

Hi,

2012/3/21 Devin Heitmueller :
>
> Every USB bridge provides their raw video over isoc in a slightly
> different format (not just in terms of the colorspace but also how to
> read the isoc header to detect the start of video frame, which field
> is being sent, etc).  Regarding the colorspace, in many cases it's
> simply 16-bit YUYV, so I would probably start there.

Ok. So, it's not saa7113 related, but rather stk1160 related?

When there is no video, isoc urbs are received with actual length=4.
This is header right?
--
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: [Q] v4l buffer format inside isoc

[Ezequiel García]

Hi,

2012/3/21 Jean-Francois Moine :
> In the gspca test tarball (see my site), I merged the spca506 code into
> the spca505 for a webcam which may also do analog video capture. The
> webcam works, but the analog video capture has never been tested.
> Also, the gspca_main <-> subdriver interface for vidioc_s_input and
> vidioc_s_std is not very clean.

I'm not sure about this. The device is based on a new chip stk1160, and
according to Mauro a new driver is needed.

Since the chip supports tuner and other stuff besides video capture,
perhaps adding a new driver might ease future development.

Anyway, with saa7115 driver and the new videobuf2/v4l interface
the driver we'll be very minimal (I hope).

Thanks.
--
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: [Q] v4l buffer format inside isoc

[Devin Heitmueller]

2012/3/21 Ezequiel García :
> 2012/3/20 Andy Walls :
>
>>
>> Section 8.10 of the SAA7113 data sheet shows 16 "data formats".  The
>> interesting one for video is #15 Y:U:V 4:2:2.

Every USB bridge provides their raw video over isoc in a slightly
different format (not just in terms of the colorspace but also how to
read the isoc header to detect the start of video frame, which field
is being sent, etc).  Regarding the colorspace, in many cases it's
simply 16-bit YUYV, so I would probably start there.

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: [Q] v4l buffer format inside isoc

[Ezequiel García]

2012/3/20 Andy Walls :

>
> Section 8.10 of the SAA7113 data sheet shows 16 "data formats".  The
> interesting one for video is #15 Y:U:V 4:2:2.

Thanks. Perhaps, I should have done my homework.

>
> The EM28xx chip programming might rearrange some data, but I have no
> knowledge or experience with the eMPIA chips.

The chip is not eMPIA, but rather stk1160. It's a new chipset that's not
currently supported (there is a similar one in stk-webcam).
--
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: media_tree daily build: ERRORS

[Hans Verkuil]

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

Results of the daily build of media_tree:

date:Wed Mar 21 19:00:39 CET 2012
git hash:f92c97c8bd77992ff8bd6ef29a23dc82dca799cb
gcc version:  i686-linux-gcc (GCC) 4.6.2
host hardware:x86_64
host os:  3.1-2.slh.1-amd64

linux-git-arm-eabi-enoxys: ERRORS
linux-git-arm-eabi-omap: ERRORS
linux-git-armv5-ixp: 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: ERRORS
linux-2.6.33-i686: ERRORS
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-3.0-i686: WARNINGS
linux-3.1-i686: WARNINGS
linux-3.2.1-i686: WARNINGS
linux-3.3-rc1-i686: WARNINGS
linux-2.6.31.12-x86_64: ERRORS
linux-2.6.32.6-x86_64: ERRORS
linux-2.6.33-x86_64: ERRORS
linux-2.6.34-x86_64: 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
linux-3.0-x86_64: WARNINGS
linux-3.1-x86_64: WARNINGS
linux-3.2.1-x86_64: WARNINGS
linux-3.3-rc1-x86_64: WARNINGS
apps: WARNINGS
spec-git: WARNINGS
sparse: ERRORS

Detailed results are available here:

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

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Wednesday.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: Move em27xx/em28xx webcams to a gspca subdriver ?

[Frank Schäfer]

Am 16.03.2012 23:18, schrieb Frank Schäfer:
> [Was: eMPIA EM2710 Webcam (em28xx) and LIRC]
>
> Continue this part of the discussion in a new thread...
>
> Am 15.03.2012 14:05, schrieb Mauro Carvalho Chehab:
>> Em 15-03-2012 09:34, Frank Schäfer escreveu:
>>> ...
>>>
>>> I would like to bring up the question, if it wouldn't make sense to move
>>> support for the em27xx/28xx webcams to a separate gspca-subdriver.
>> The em2710/2750 chips are very similar to em2820. There's not much sense
>> on moving it elsewhere, as it would duplicate a lot of the existing code,
>> for no good reason.
> Yes, that was my first thought, too.
> But looking at the resulting gspca subdriver, you will see that there is
> not much code duplication.
> I would say that adding support for this device as a gspca subdriver
> requires less new lines of code than extending/modifying the em28xx driver.
>
>>> I'm currently working on adding support for the VAD Laplace webcam
>>> (em2765 + OV2640) (http://linuxtv.org/wiki/index.php/VAD_Laplace).
>>> Lots of modifications to the em28xx driver would be necessary to support
>>> this device because of some significant differences:
>>> - supports only bulk transfers
>> em28xx supports it as well, but it is used only for dvb, currently.
> You are talking about the em28xx device capabilities, right ?
> AFAIK, the em28xx driver still has no bulk transfer support.
>
>>> - uses proprietary I2C-writes
>> huh? I2C writes are proprietary. What do you mean?
> Maybe proprietary is not the best name...
> Requests 0x06 an 0x08 are used for the usb control messages.
> I have documented that at http://linuxtv.org/wiki/index.php/VAD_Laplace.
> Could be the "vendor specific" usb requests the datasheet talks about.
>
>>> - em25xx-eeprom
>> Are you meaning more than 256 addresses eeprom? Newer Empia chips use it,
>> not only the webcam ones. Currently, the code detects it but nobody wrote
>> an implementation for it yet. It would likely make sense to implement it
>> at em28xx anyway.
> Yes, the device has an eeprom with 16bit addresses.
> Anyway, I'm talking about a different format of the eeprom data:
> http://wenku.baidu.com/view/a21a28eab8f67c1cfad6b8f6.html
>
> You can find the eeprom content of my device at
> http://linuxtv.org/wiki/index.php/VAD_Laplace
>
>>> - ov2640 sensor
>> The better is to use a separate I2C driver for the sensor. This is not
>> a common practice at gspca, but doing that would help to re-use the sensor
>> driver elsewhere.
> I agree. But let's do things step by step...
>
>>> Lots of changes concerning the USB-interface probing, button handling,
>>> video controls, frame processing and more would be necessary, too.
>> Video controls are implemented at the sensor sub-driver, so this is not
>> an issue.
>>
>> Anyway, if em2765 is different enough from em2874 and em2750, then it makes
>> sense to write it as a separate driver. Otherwise, it is better to add 
>> support
>> for it there.
> No, the em2765 itself seems to be very similar to the other
> em27xx/em28xx chips.
> But the device as a whole is different enough to consider a separate driver.
>
>>> For reverse engineering purposes, I decided to write a gspca subdriver
>>> for this device (will send a patch for testing/discussion soon).
>> Ok.
> See the patch posted a minute ago.
>
>>> I have no strong opinion about this, but I somehow feel that the em28xx
>>> driver gets bloated more and more...
>> The advantage of adding it there is that it generally reduces maintenance 
>> efforts, as the same code and fixes don't need to be added on two separate
>> places.
> Yes, that's right. But on the other hand, the benefit of separate
> drivers is simpler code, which is easier to maintain/understand.
> For example, there would be no LIRC modules issue ;-)
>
>> For example, if the em2765 eeprom access is similar to em2874, the same
>> code chunk would be required on both drivers.
> Sure, code duplication is one of the disadvantages. The question is how
> much duplicate code there would be.
>
> Regards,
> Frank
>
>> Regards,
>> Mauro
Ping !
No comments, opinions ? ;-)

Regards,
Frank

--
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] [RFT/RFC] Add gspca subdriver for Speedlink VAD Laplace (EM2765+OV2640)

[Frank Schäfer]

Am 17.03.2012 14:11, schrieb Jean-Francois Moine:
> On Fri, 16 Mar 2012 23:15:45 +0100
> Frank Schäfer  wrote:
>
>> Anyway, I would be glad to get some feedback concerning form and content of 
>> the code, becausse I'm still a newbie to kernel programming.
> Hi Frank,
>
> I agree that writing a new gspca subdriver is easier than extending some
> other video driver...
>
> Here are some remarks:
>
> - you should not start the workqueue button_check immediately because
>   the webcam hardware is not fully initialized in sd_config().
>   Instead, you may check gspca_dev->present or have a greater delay
>   (1s) in sd_config(). This also avoids to patch the gspca main.
>
> - usually, the sensor reset ('12 80' for Omnivision - 2nd item in
>   ov2640_init) asks for some time. So, a little delay (200 ms) is
>   welcome.
>
> - I am not sure that looping on usb_control_msg() on read or write error
>   does help.
>
> - the debug flags D_USBI and D_USBO are no more available. It is easier
>   to use usbmon to trace the exchanges.
>
> - using the new control mechanism removes a lot of code (see stk014.c).
>
> - using the gspca variable 'usb_err' avoids testing each USB write
>   (during probe, you may use a flag to skip printing error messages).
>
> - in the form:
>
>   - you must use
>
>   module_usb_driver(sd_driver);
>
> to replace the module stuff.
>
>   - don't use C++ comments
>
> - the code may be optimized, as replacing the sequences of
>   write_prop_single() calls by a loop and a table.
>
> Best regards.
>

Hi Jean-Francois,

thanks for your remarks !
I will incoorporate them in case that a decision for a gspca subdriver
is made.

Regards,
Frank
--
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] [RFC] dma-buf: mmap support

[Rebecca Schultz Zavin]

On Wed, Mar 21, 2012 at 8:45 AM, Rob Clark  wrote:
> On Tue, Mar 20, 2012 at 3:53 PM, Daniel Vetter  wrote:
>> Let's have some competition here for dma_buf mmap support ;-)
>>
>> Compared to Rob Clarke's RFC I've ditched the prepare/finish hooks
>> and corresponding ioctls on the dma_buf file. The major reason for
>> that is that many people seem to be under the impression that this is
>> also for synchronization with outstanding asynchronous processsing.
>> I'm pretty massively opposed to this because:
>>
>> - It boils down reinventing a new rather general-purpose userspace
>>  synchronization interface. If we look at things like futexes, this
>>  is hard to get right.
>> - Furthermore a lot of kernel code has to interact with this
>>  synchronization primitive. This smells a look like the dri1 hw_lock,
>>  a horror show I prefer not to reinvent.
>> - Even more fun is that multiple different subsystems would interact
>>  here, so we have plenty of opportunities to create funny deadlock
>>  scenarios.
>>
>> I think synchronization is a wholesale different problem from data
>> sharing and should be tackled as an orthogonal problem.
>
> fwiw, I was debating about two approaches before I sent initial RFC..
> with or without the ioctl's.
>
> I do agree that trying to hide synchronization behind those is likely
> to be asking for trouble.  Although I think it is partially a symptom
> of missing a synchronization primitive that we could use.  (Ie. when
> all you have is a hammer, everything looks like a nail.)
>

I'm in 100% agreement with you both on synchronization being a
separate problem.  The android team is working on a generic solution
for that as well, expect to see some of it coming across this list in
the next few weeks.  I do hate the idea that an implementer might
abuse this api for that purpose.

> On the other hand, it does significantly ease dealing with cached
> buffers, and seems useful for other debugging purposes (verifying
> userspace isn't accessing buffers when they shouldn't.  And adding
> required ioctls later is an API change.  Which was why I was leaning
> towards the approach of including ioctls but just reviewing closely
> the patches that add driver support.
>
> But, I have one idea.  What about including the ioctls, but just
> leaving them stubbed out (ie. not including the dmabuf ops).  It at
> least prevents drivers from abusing it, while leaving the API in place
> for userspace to avoid changing API to kernel later in a way that
> might break userspace.
>
> Other than that, the patch looks good.. including the extra
> error/sanity checking and documentation, which I really skimped on for
> the first version.  (I mainly just wanted to get the flame-war over
> ioctls going with the first version :-P)
>
> BR,
> -R
>
>> Now we could demand that prepare/finish may only ensure cache
>> coherency (as Rob intended), but that runs up into the next problem:
>> We not only need mmap support to facilitate sw-only processing nodes
>> in a pipeline (without jumping through hoops by importing the dma_buf
>> into some sw-access only importer), which allows for a nicer
>> ION->dma-buf upgrade path for existing Android userspace. We also need
>> mmap support for existing importing subsystems to support existing
>> userspace libraries. And a loot of these subsystems are expected to
>> export coherent userspace mappings.
>>
>> So prepare/finish can only ever be optional and the exporter /needs/
>> to support coherent mappings. Given that mmap access is always
>> somewhat fallback-y in nature I've decided to drop this optimization,
>> instead of just making it optional. If we demonstrate a clear need for
>> this, supported by benchmark results, we can always add it in again
>> later as an optional extension.
>>
>> Other differences compared to Rob's RFC is the above mentioned support
>> for mapping a dma-buf through facilities provided by the importer.
>> Which results in mmap support no longer being optional.
>>
>> Note taht this dma-buf mmap patch does _not_ support every possible
>> insanity an existing subsystem could pull of with mmap: Because it
>> does not allow to intercept pagefaults and shoot down ptes importing
>> subsystems can't add some magic of their own at these points (e.g. to
>> automatically synchronize with outstanding rendering or set up some
>> special resources). I've done a cursory read through a few mmap
>> implementions of various subsytems and I'm hopeful that we can avoid
>> this (and the complexity it'd bring with it).
>>
>> Additonally I've extended the documentation a bit to explain the hows
>> and whys of this mmap extension.
>>
>> Comments, reviews and flames highly welcome.
>>
>> Cheers, Daniel
>> ---
>>  Documentation/dma-buf-sharing.txt |   84 
>> +---
>>  drivers/base/dma-buf.c            |   64 +++-
>>  include/linux/dma-buf.h           |   16 +++
>>  3 files changed, 156 insertions(+), 8 deletions(-)
>>

[PATCH 2/2] Integrate Fitipower fc0011 into af903x

[Michael Büsch]

This adds fc0011 support to the af903x driver.

Signed-off-by: Michael Buesch 

---


Index: linux-source-3.2/drivers/media/dvb/dvb-usb/Kconfig
===
--- linux-source-3.2.orig/drivers/media/dvb/dvb-usb/Kconfig 2012-03-20 
22:48:14.025859279 +0100
+++ linux-source-3.2/drivers/media/dvb/dvb-usb/Kconfig  2012-03-21 
15:31:43.266801632 +0100
@@ -342,6 +342,7 @@
 config DVB_USB_AF903X
tristate "Afatech AF903X DVB-T USB2.0 support"
depends on DVB_USB && EXPERIMENTAL
+   select MEDIA_TUNER_FC0011   if !MEDIA_TUNER_CUSTOMISE
select MEDIA_TUNER_FC0012   if !MEDIA_TUNER_CUSTOMISE
select MEDIA_TUNER_MXL5007T if !MEDIA_TUNER_CUSTOMISE
help
Index: linux-source-3.2/drivers/media/dvb/dvb-usb/af903x-devices.c
===
--- linux-source-3.2.orig/drivers/media/dvb/dvb-usb/af903x-devices.c
2012-03-20 22:48:14.025859279 +0100
+++ linux-source-3.2/drivers/media/dvb/dvb-usb/af903x-devices.c 2012-03-21 
15:31:43.270801692 +0100
@@ -260,6 +260,7 @@
 }
 
 extern struct tuner_desc tuner_af9007;
+extern struct tuner_desc tuner_fc0011;
 extern struct tuner_desc tuner_fc0012;
 extern struct tuner_desc tuner_mxl5007t;
 
@@ -273,6 +274,9 @@
case TUNER_AF9007:
ctx->tuner_desc = &tuner_af9007;
break;
+   case TUNER_FC0011:
+   ctx->tuner_desc = &tuner_fc0011;
+   break;
case TUNER_FC0012:
ctx->tuner_desc = &tuner_fc0012;
break;
Index: linux-source-3.2/drivers/media/dvb/dvb-usb/af903x-fe.c
===
--- linux-source-3.2.orig/drivers/media/dvb/dvb-usb/af903x-fe.c 2012-03-20 
22:48:14.025859279 +0100
+++ linux-source-3.2/drivers/media/dvb/dvb-usb/af903x-fe.c  2012-03-21 
15:37:04.968319280 +0100
@@ -28,6 +28,7 @@
 #include "af903x-fe.h"
 #include "af903x-fe-priv.h"
 #include "dvb_frontend.h"
+#include "fc0011.h"
 #include "fc0012.h"
 #include "mxl5007t.h"
 
@@ -1967,6 +1968,8 @@
}
 };
 
+extern int af903x_fc0011_reset(void *_ctx);
+
 static struct dvb_frontend_ops af903x_ops;
 struct dvb_frontend *af903x_fe_attach(struct i2c_adapter *i2c_adap, int id,
struct af903x_dev_ctx *ctx)
@@ -1990,6 +1993,13 @@
switch(ctx->tuner_desc->tunerId) {
case TUNER_AF9007:
break;
+   case TUNER_FC0011:
+   ret = dvb_attach(fc0011_attach, frontend, i2c_adap,
+   id == 0 ? ctx->tuner_desc->tuner_addr :
+   ctx->tuner_desc->tuner_addr + 1,
+   af903x_fc0011_reset, ctx)
+   == NULL ?  -ENODEV : 0;
+   break;
case TUNER_FC0012:
ret = dvb_attach(fc0012_attach, frontend, i2c_adap,
id == 0 ? ctx->tuner_desc->tuner_addr :
Index: linux-source-3.2/drivers/media/dvb/dvb-usb/af903x-tuners.c
===
--- linux-source-3.2.orig/drivers/media/dvb/dvb-usb/af903x-tuners.c 
2012-03-20 22:48:14.025859279 +0100
+++ linux-source-3.2/drivers/media/dvb/dvb-usb/af903x-tuners.c  2012-03-21 
15:42:42.214115654 +0100
@@ -189,6 +189,69 @@
{0xf1e6, 0x00},
 };
 
+static u16 fc0011_script_sets[] = {
+   0x38,
+};
+
+static struct af903x_val_set fc0011_scripts[] = {
+   {0x0046, 0x28}, /* TUNER_ID */
+   {0x0057, 0x00},
+   {0x0058, 0x01},
+   {0x005f, 0x00},
+   {0x0060, 0x00},
+   {0x0068, 0xa5},
+   {0x006e, 0x01},
+   {0x0071, 0x0A},
+   {0x0072, 0x02},
+   {0x0074, 0x01},
+   {0x0079, 0x01},
+   {0x0093, 0x00},
+   {0x0094, 0x00},
+   {0x0095, 0x00},
+   {0x0096, 0x00},
+   {0x009b, 0x2D},
+   {0x009c, 0x60},
+   {0x009d, 0x23},
+   {0x00a4, 0x50},
+   {0x00ad, 0x50},
+   {0x00b3, 0x01},
+   {0x00b7, 0x88},
+   {0x00b8, 0xa6},
+   {0x00c3, 0x01},
+   {0x00c4, 0x01},
+   {0x00c7, 0x69},
+   {0xF007, 0x00},
+   {0xF00A, 0x1B},
+   {0xF00B, 0x1B},
+   {0xF00C, 0x1B},
+   {0xF00D, 0x1B},
+   {0xF00E, 0xFF},
+   {0xF00F, 0x01},
+   {0xF010, 0x00},
+   {0xF011, 0x02},
+   {0xF012, 0xFF},
+   {0xF013, 0x01},
+   {0xF014, 0x00},
+   {0xF015, 0x02},
+   {0xF01B, 0xEF},
+   {0xF01C, 0x01},
+   {0xF01D, 0x0f},
+   {0xF01E, 0x02},
+   {0xF01F, 0x6E},
+   {0xF020, 0x00},
+   {0xF025, 0xDE},
+   {0xF026, 0x00},
+   {0xF027, 0x0A},
+   {0xF028, 0x03},
+   {0xF029, 0x6E},
+   {0xF02A, 0x00},
+   {0xF047, 0x00},
+   {0xF054, 0x0},
+   {0xF055, 0x0},
+   {0xF077, 0x01},
+   {0xF1E6, 0x00},
+};
+
 static int af903x_fc0012_init(struct af903x_dev_ctx *ctx, int chip)
 {
int ret;
@@ -338,6 +401,43 @@
TUNER_FC0012,
 };
 
+int af903x_fc0011_reset(void *_ctx)
+{
+  

[PATCH 1/2] Fitipower fc0011 driver

[Michael Büsch]

This adds the Fitipower fc0011 tuner driver.

Note: The '#if 0' statements will be removed on the final submission.

Signed-off-by: Michael Buesch 

---

Index: linux-source-3.2/drivers/media/common/tuners/Kconfig
===
--- linux-source-3.2.orig/drivers/media/common/tuners/Kconfig   2012-03-21 
15:43:23.658828874 +0100
+++ linux-source-3.2/drivers/media/common/tuners/Kconfig2012-03-21 
15:43:27.442894007 +0100
@@ -204,6 +204,13 @@
help
  NXP TDA18212 silicon tuner driver.
 
+config MEDIA_TUNER_FC0011
+   tristate "Fitipower FC0011 silicon tuner"
+   depends on VIDEO_MEDIA && I2C
+   default m if MEDIA_TUNER_CUSTOMISE
+   help
+ Fitipower FC0011 silicon tuner driver.
+
 config MEDIA_TUNER_FC0012
tristate "Fitipower FC0012 silicon tuner"
depends on VIDEO_MEDIA && I2C
Index: linux-source-3.2/drivers/media/common/tuners/Makefile
===
--- linux-source-3.2.orig/drivers/media/common/tuners/Makefile  2012-03-21 
15:43:23.658828874 +0100
+++ linux-source-3.2/drivers/media/common/tuners/Makefile   2012-03-21 
15:43:27.446894082 +0100
@@ -27,6 +27,7 @@
 obj-$(CONFIG_MEDIA_TUNER_MAX2165) += max2165.o
 obj-$(CONFIG_MEDIA_TUNER_TDA18218) += tda18218.o
 obj-$(CONFIG_MEDIA_TUNER_TDA18212) += tda18212.o
+obj-$(CONFIG_MEDIA_TUNER_FC0011) += fc0011.o
 obj-$(CONFIG_MEDIA_TUNER_FC0012) += fc0012.o
 
 ccflags-y += -Idrivers/media/dvb/dvb-core
Index: linux-source-3.2/drivers/media/common/tuners/fc0011.c
===
--- /dev/null   1970-01-01 00:00:00.0 +
+++ linux-source-3.2/drivers/media/common/tuners/fc0011.c   2012-03-21 
15:52:28.048214689 +0100
@@ -0,0 +1,501 @@
+/*
+ * Fitipower FC0011 tuner driver
+ *
+ * Copyright (C) 2012 Michael Buesch 
+ *
+ * Derived from FC0012 tuner driver:
+ * Copyright (C) 2012 Hans-Frieder Vogt 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include "fc0011.h"
+
+
+/* Tuner registers */
+enum {
+   FC11_REG_0,
+   FC11_REG_FA,/* FA */
+   FC11_REG_FP,/* FP */
+   FC11_REG_XINHI, /* XIN high 8 bit */
+   FC11_REG_XINLO, /* XIN low 8 bit */
+   FC11_REG_VCO,   /* VCO */
+   FC11_REG_VCOSEL,/* VCO select */
+   FC11_REG_7, /* Unknown tune reg 7 */
+   FC11_REG_8, /* Unknown tune reg 8 */
+   FC11_REG_9,
+   FC11_REG_10,/* Unknown tune reg 10 */
+   FC11_REG_11,/* Unknown tune reg 11 */
+   FC11_REG_12,
+   FC11_REG_RCCAL, /* RC calibrate */
+   FC11_REG_VCOCAL,/* VCO calibrate */
+   FC11_REG_15,
+   FC11_REG_16,/* Unknown tune reg 16 */
+   FC11_REG_17,
+
+   FC11_NR_REGS,   /* Number of registers */
+};
+
+enum FC11_REG_VCOSEL_bits {
+   FC11_VCOSEL_2   = 0x08, /* VCO select 2 */
+   FC11_VCOSEL_1   = 0x10, /* VCO select 1 */
+   FC11_VCOSEL_CLKOUT  = 0x20, /* Fix clock out */
+   FC11_VCOSEL_BW7M= 0x40, /* 7MHz bw */
+   FC11_VCOSEL_BW6M= 0x80, /* 6MHz bw */
+};
+
+enum FC11_REG_RCCAL_bits {
+   FC11_RCCAL_FORCE= 0x10, /* force */
+};
+
+enum FC11_REG_VCOCAL_bits {
+   FC11_VCOCAL_RUN = 0,/* VCO calibration run */
+   FC11_VCOCAL_VALUEMASK   = 0x3F, /* VCO calibration value mask */
+   FC11_VCOCAL_OK  = 0x40, /* VCO calibration Ok */
+   FC11_VCOCAL_RESET   = 0x80, /* VCO calibration reset */
+};
+
+
+struct fc0011_priv {
+   struct i2c_adapter *i2c;
+   u8 addr;
+
+   u32 frequency;
+   u32 bandwidth;
+
+   int (*tuner_reset)(void *data);
+   void *tuner_reset_data;
+};
+
+
+static int fc0011_writereg(struct fc0011_priv *priv, u8 reg, u8 val)
+{
+   u8 buf[2] = { reg, val };
+   struct i2c_msg msg = { .addr = priv->addr,
+   .flags = 0, .buf = buf, .len = 2 };
+
+   msleep(1);
+   if (i2c_transfer(priv->i2c, &msg, 1) != 1) {
+   dev_err(&priv->i2c->dev,
+   "I2C write reg failed, reg: %02x, val: %02x\n",
+   reg, val);
+   return -EIO;
+   

[PATCH 0/2] Fitipower fc0011 support

[Michael Büsch]

This patchset adds support for the Fitipower fc0011 DVB tuner.

Version 2 of this patchset fixes several small bugs and adds
some descriptive register names.

-- 
Greetings, Michael.

PGP encryption is encouraged / 908D8B0E


signature.asc
Description: PGP signature

[GIT PATCHES FOR 3.4] s5p/exynos fimc driver updates

[Sylwester Nawrocki]

Hello Mauro,

please pull the following, if it isn't too late yet, for v3.4. The last patch
doesn't apply cleanly to linuxtv/staging/for_v3.4, due to some changes that
are already in Linus' tree. Also this conflicting patch depends on commit 
d1c3414c2a9d10ef7f "drivercore: Add driver probe deferral mechanism"
So the patches for this pull request are based on Linus' tree, with the 
staging/for_v3.4 branch merged to it. Please let me know if this should be
handled differently. 

The following changes since commit bcc15c27c75187016f4402d94967f74b7571bacc:

  Merge remote-tracking branch 'linuxtv/staging/for_v3.4' into fimc-for-next 
(2012-03-21 10:19:36 +0100)

are available in the git repository at:


  git://git.infradead.org/users/kmpark/linux-samsung fimc-for-next

for you to fetch changes up to 6576f95e4d74877cf8b385e7591959f78f300dc7:

  s5p-fimc: Handle sub-device interdependencies using deferred probing 
(2012-03-21 13:58:09 +0100)


Sylwester Nawrocki (6):
  s5p-fimc: Don't use platform data for CSI data alignment configuration
  s5p-fimc: Reinitialize the pipeline properly after VIDIOC_STREAMOFF
  s5p-fimc: Simplify locking by removing the context data structure spinlock
  s5p-fimc: Refactor hardware setup for m2m transaction
  s5p-fimc: Remove unneeded fields from struct fimc_dev
  s5p-fimc: Handle sub-device interdependencies using deferred probing

 drivers/media/video/s5p-fimc/fimc-capture.c |   33 
 drivers/media/video/s5p-fimc/fimc-core.c|  110 ---
 drivers/media/video/s5p-fimc/fimc-core.h|   18 ++---
 drivers/media/video/s5p-fimc/fimc-mdevice.c |   69 +
 drivers/media/video/s5p-fimc/fimc-reg.c |3 +-
 drivers/media/video/s5p-fimc/mipi-csis.c|   21 ++---
 6 files changed, 119 insertions(+), 135 deletions(-)


Thank you,
-- 
Sylwester Nawrocki
Samsung Poland R&D 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: [PATCH] [RFC] dma-buf: mmap support

[Rob Clark]

On Tue, Mar 20, 2012 at 3:53 PM, Daniel Vetter  wrote:
> Let's have some competition here for dma_buf mmap support ;-)
>
> Compared to Rob Clarke's RFC I've ditched the prepare/finish hooks
> and corresponding ioctls on the dma_buf file. The major reason for
> that is that many people seem to be under the impression that this is
> also for synchronization with outstanding asynchronous processsing.
> I'm pretty massively opposed to this because:
>
> - It boils down reinventing a new rather general-purpose userspace
>  synchronization interface. If we look at things like futexes, this
>  is hard to get right.
> - Furthermore a lot of kernel code has to interact with this
>  synchronization primitive. This smells a look like the dri1 hw_lock,
>  a horror show I prefer not to reinvent.
> - Even more fun is that multiple different subsystems would interact
>  here, so we have plenty of opportunities to create funny deadlock
>  scenarios.
>
> I think synchronization is a wholesale different problem from data
> sharing and should be tackled as an orthogonal problem.

fwiw, I was debating about two approaches before I sent initial RFC..
with or without the ioctl's.

I do agree that trying to hide synchronization behind those is likely
to be asking for trouble.  Although I think it is partially a symptom
of missing a synchronization primitive that we could use.  (Ie. when
all you have is a hammer, everything looks like a nail.)

On the other hand, it does significantly ease dealing with cached
buffers, and seems useful for other debugging purposes (verifying
userspace isn't accessing buffers when they shouldn't.  And adding
required ioctls later is an API change.  Which was why I was leaning
towards the approach of including ioctls but just reviewing closely
the patches that add driver support.

But, I have one idea.  What about including the ioctls, but just
leaving them stubbed out (ie. not including the dmabuf ops).  It at
least prevents drivers from abusing it, while leaving the API in place
for userspace to avoid changing API to kernel later in a way that
might break userspace.

Other than that, the patch looks good.. including the extra
error/sanity checking and documentation, which I really skimped on for
the first version.  (I mainly just wanted to get the flame-war over
ioctls going with the first version :-P)

BR,
-R

> Now we could demand that prepare/finish may only ensure cache
> coherency (as Rob intended), but that runs up into the next problem:
> We not only need mmap support to facilitate sw-only processing nodes
> in a pipeline (without jumping through hoops by importing the dma_buf
> into some sw-access only importer), which allows for a nicer
> ION->dma-buf upgrade path for existing Android userspace. We also need
> mmap support for existing importing subsystems to support existing
> userspace libraries. And a loot of these subsystems are expected to
> export coherent userspace mappings.
>
> So prepare/finish can only ever be optional and the exporter /needs/
> to support coherent mappings. Given that mmap access is always
> somewhat fallback-y in nature I've decided to drop this optimization,
> instead of just making it optional. If we demonstrate a clear need for
> this, supported by benchmark results, we can always add it in again
> later as an optional extension.
>
> Other differences compared to Rob's RFC is the above mentioned support
> for mapping a dma-buf through facilities provided by the importer.
> Which results in mmap support no longer being optional.
>
> Note taht this dma-buf mmap patch does _not_ support every possible
> insanity an existing subsystem could pull of with mmap: Because it
> does not allow to intercept pagefaults and shoot down ptes importing
> subsystems can't add some magic of their own at these points (e.g. to
> automatically synchronize with outstanding rendering or set up some
> special resources). I've done a cursory read through a few mmap
> implementions of various subsytems and I'm hopeful that we can avoid
> this (and the complexity it'd bring with it).
>
> Additonally I've extended the documentation a bit to explain the hows
> and whys of this mmap extension.
>
> Comments, reviews and flames highly welcome.
>
> Cheers, Daniel
> ---
>  Documentation/dma-buf-sharing.txt |   84 +---
>  drivers/base/dma-buf.c            |   64 +++-
>  include/linux/dma-buf.h           |   16 +++
>  3 files changed, 156 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/dma-buf-sharing.txt 
> b/Documentation/dma-buf-sharing.txt
> index a6d4c37..c42a4a5 100644
> --- a/Documentation/dma-buf-sharing.txt
> +++ b/Documentation/dma-buf-sharing.txt
> @@ -29,13 +29,6 @@ The buffer-user
>    in memory, mapped into its own address space, so it can access the same 
> area
>    of memory.
>
> -*IMPORTANT*: [see https://lkml.org/lkml/2011/12/20/211 for more details]
> -For this first version, A buffer shared using the d

Re: [PATCH 05/16] mm/drivers: use vm_flags_t for vma flags

[Greg Kroah-Hartman]

On Wed, Mar 21, 2012 at 10:56:33AM +0400, Konstantin Khlebnikov wrote:
> Signed-off-by: Konstantin Khlebnikov 
> Cc: linux-media@vger.kernel.org
> Cc: de...@driverdev.osuosl.org
> Cc: Laurent Pinchart 
> Cc: Mauro Carvalho Chehab 
> Cc: Greg Kroah-Hartman 
> Cc: John Stultz 
> Cc: "Arve Hjønnevåg" 

Acked-by: Greg Kroah-Hartman 

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

Re: [GIT PULL FOR v3.4] V4L2 subdev and sensor control changes and SMIA++ driver

[Sakari Ailus]

Hi Prabhakar,

Prabhakar Lad wrote:

On Tue, Mar 20, 2012 at 4:24 AM, Sakari Ailus  wrote:

Hi Mauro,

On Mon, Mar 19, 2012 at 06:47:28PM -0300, Mauro Carvalho Chehab wrote:

Em 11-03-2012 13:56, Sakari Ailus escreveu:

Hi Mauro,

This patchset adds

- Integer menu controls,
- Selection IOCTL for subdevs,
- Sensor control improvements,
- link_validate() media entity and V4L2 subdev pad ops,
- OMAP 3 ISP driver improvements,
- SMIA++ sensor driver and
- Other V4L2 and media improvements (see individual patches)

The previous patchset can be found here:

http://www.spinics.net/lists/linux-media/msg45052.html>

Compared to the patchset, I've dropped the rm-696 camera board code and will
submit it through linux-omap later on. Other changes done to address review
comments have been also done --- see the URL above for details.

The following changes since commit 632fba4d012458fd5fedc678fb9b0f8bc59ceda2:

   [media] cx25821: Add a card definition for "No brand" cards that have: 
subvendor = 0x subdevice = 0x (2012-03-08 12:42:28 -0300)

are available in the git repository at:
   ssh://linuxtv.org/git/sailus/media_tree.git media-for-3.4

Jesper Juhl (1):
   adp1653: Remove unneeded include of version.h

Laurent Pinchart (3):
   omap3isp: Prevent pipelines that contain a crashed entity from starting
   omap3isp: Fix crash caused by subdevs now having a pointer to devnodes
   omap3isp: Fix frame number propagation

Sakari Ailus (37):
   v4l: Introduce integer menu controls
   v4l: Document integer menu controls
   vivi: Add an integer menu test control
   v4l: VIDIOC_SUBDEV_S_SELECTION and VIDIOC_SUBDEV_G_SELECTION IOCTLs
   v4l: vdev_to_v4l2_subdev() should have return type "struct v4l2_subdev *"
   v4l: Check pad number in get try pointer functions
   v4l: Support s_crop and g_crop through s/g_selection
   v4l: Add subdev selections documentation: svg and dia files
   v4l: Add subdev selections documentation


This patch broke docbook compilation:

   HTMLDocumentation/DocBook/media_api.html
warning: failed to load external entity 
"/home/v4l/v4l/patchwork/Documentation/DocBook/vidioc-subdev-g-selection.xml"
/home/v4l/v4l/patchwork/Documentation/DocBook/dev-subdev.xml:310: parser error 
: Failure to process entity sub-subdev-g-selection
   size configured using&sub-subdev-g-selection; and
 ^
/home/v4l/v4l/patchwork/Documentation/DocBook/dev-subdev.xml:310: parser error 
: Entity 'sub-subdev-g-selection' not defined
   size configured using&sub-subdev-g-selection; and
 ^
/home/v4l/v4l/patchwork/Documentation/DocBook/dev-subdev.xml:468: parser error 
: chunk is not well balanced

^
/home/v4l/v4l/patchwork/Documentation/DocBook/v4l2.xml:476: parser error : 
Failure to process entity sub-dev-subdev
   &sub-dev-subdev;
   ^
/home/v4l/v4l/patchwork/Documentation/DocBook/v4l2.xml:476: parser error : 
Entity 'sub-dev-subdev' not defined
   &sub-dev-subdev;
   ^
/usr/bin/xmlto: line 568:  3232 Segmentation fault  "/usr/bin/xsltproc" --nonet --xinclude --param 
passivetex.extensions '1' -o "/tmp/xmlto.J0M0go/media_api.proc" "/tmp/xmlto-xsl.GKa5kH" 
"/home/v4l/v4l/patchwork/Documentation/DocBook/media_api.xml"
/bin/cp: cannot stat `*.*htm*': No such file or directory
make[1]: *** [Documentation/DocBook/media_api.html] Error 1
make: *** [htmldocs] Error 2

Please fix.


I'm pretty sure it compiles for me --- I just tested it myself on a
different machine. Do you think you could possibly have e.g. old
Documentation/DocBook/media-entities.tmpl in your tree? This file
sometimes isn't getting rebuilt even when it would be needed to.


   Even I am facing a similar kind of issue where
  Documentation/DocBook/media-entities.tmpl is not getting rebuilt how to fix 
it?


Please run "make cleandocs" first.

Alternatively one could change the Makefile so that these temporary 
files are always rebuilt when building the DocBook documentation, or 
even so that these temporary files would depend on the proper source xml 
files.


Kind regards,

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

Re: [GIT PULL FOR v3.4] V4L2 subdev and sensor control changes and SMIA++ driver

[Prabhakar Lad]

Sakari,

On Tue, Mar 20, 2012 at 4:24 AM, Sakari Ailus  wrote:
> Hi Mauro,
>
> On Mon, Mar 19, 2012 at 06:47:28PM -0300, Mauro Carvalho Chehab wrote:
>> Em 11-03-2012 13:56, Sakari Ailus escreveu:
>> > Hi Mauro,
>> >
>> > This patchset adds
>> >
>> > - Integer menu controls,
>> > - Selection IOCTL for subdevs,
>> > - Sensor control improvements,
>> > - link_validate() media entity and V4L2 subdev pad ops,
>> > - OMAP 3 ISP driver improvements,
>> > - SMIA++ sensor driver and
>> > - Other V4L2 and media improvements (see individual patches)
>> >
>> > The previous patchset can be found here:
>> >
>> > http://www.spinics.net/lists/linux-media/msg45052.html>
>> >
>> > Compared to the patchset, I've dropped the rm-696 camera board code and 
>> > will
>> > submit it through linux-omap later on. Other changes done to address review
>> > comments have been also done --- see the URL above for details.
>> >
>> > The following changes since commit 
>> > 632fba4d012458fd5fedc678fb9b0f8bc59ceda2:
>> >
>> >   [media] cx25821: Add a card definition for "No brand" cards that have: 
>> > subvendor = 0x subdevice = 0x (2012-03-08 12:42:28 -0300)
>> >
>> > are available in the git repository at:
>> >   ssh://linuxtv.org/git/sailus/media_tree.git media-for-3.4
>> >
>> > Jesper Juhl (1):
>> >       adp1653: Remove unneeded include of version.h
>> >
>> > Laurent Pinchart (3):
>> >       omap3isp: Prevent pipelines that contain a crashed entity from 
>> > starting
>> >       omap3isp: Fix crash caused by subdevs now having a pointer to 
>> > devnodes
>> >       omap3isp: Fix frame number propagation
>> >
>> > Sakari Ailus (37):
>> >       v4l: Introduce integer menu controls
>> >       v4l: Document integer menu controls
>> >       vivi: Add an integer menu test control
>> >       v4l: VIDIOC_SUBDEV_S_SELECTION and VIDIOC_SUBDEV_G_SELECTION IOCTLs
>> >       v4l: vdev_to_v4l2_subdev() should have return type "struct 
>> > v4l2_subdev *"
>> >       v4l: Check pad number in get try pointer functions
>> >       v4l: Support s_crop and g_crop through s/g_selection
>> >       v4l: Add subdev selections documentation: svg and dia files
>> >       v4l: Add subdev selections documentation
>>
>> This patch broke docbook compilation:
>>
>>   HTML    Documentation/DocBook/media_api.html
>> warning: failed to load external entity 
>> "/home/v4l/v4l/patchwork/Documentation/DocBook/vidioc-subdev-g-selection.xml"
>> /home/v4l/v4l/patchwork/Documentation/DocBook/dev-subdev.xml:310: parser 
>> error : Failure to process entity sub-subdev-g-selection
>>       size configured using &sub-subdev-g-selection; and
>>                                                     ^
>> /home/v4l/v4l/patchwork/Documentation/DocBook/dev-subdev.xml:310: parser 
>> error : Entity 'sub-subdev-g-selection' not defined
>>       size configured using &sub-subdev-g-selection; and
>>                                                     ^
>> /home/v4l/v4l/patchwork/Documentation/DocBook/dev-subdev.xml:468: parser 
>> error : chunk is not well balanced
>>
>> ^
>> /home/v4l/v4l/patchwork/Documentation/DocBook/v4l2.xml:476: parser error : 
>> Failure to process entity sub-dev-subdev
>>      &sub-dev-subdev; 
>>                                           ^
>> /home/v4l/v4l/patchwork/Documentation/DocBook/v4l2.xml:476: parser error : 
>> Entity 'sub-dev-subdev' not defined
>>      &sub-dev-subdev; 
>>                                           ^
>> /usr/bin/xmlto: line 568:  3232 Segmentation fault      "/usr/bin/xsltproc" 
>> --nonet --xinclude --param passivetex.extensions '1' -o 
>> "/tmp/xmlto.J0M0go/media_api.proc" "/tmp/xmlto-xsl.GKa5kH" 
>> "/home/v4l/v4l/patchwork/Documentation/DocBook/media_api.xml"
>> /bin/cp: cannot stat `*.*htm*': No such file or directory
>> make[1]: *** [Documentation/DocBook/media_api.html] Error 1
>> make: *** [htmldocs] Error 2
>>
>> Please fix.
>
> I'm pretty sure it compiles for me --- I just tested it myself on a
> different machine. Do you think you could possibly have e.g. old
> Documentation/DocBook/media-entities.tmpl in your tree? This file
> sometimes isn't getting rebuilt even when it would be needed to.
>
  Even I am facing a similar kind of issue where
 Documentation/DocBook/media-entities.tmpl is not getting rebuilt how to fix it?

Regards,
--Prabhakar Lad

> Kind regards,
>
> --
> Sakari Ailus
> e-mail: sakari.ai...@iki.fi     jabber/XMPP/Gmail: sai...@retiisi.org.uk
> --
> 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 v5.5 14/40] v4l: Add DPCM compressed raw bayer pixel formats

[Prabhakar Lad]

On Wed, Mar 21, 2012 at 5:14 PM, Sakari Ailus  wrote:
>
> Add three other colour orders for 10-bit to 8-bit DPCM compressed raw
> bayer
> pixel formats.
>
> Signed-off-by: Sakari Ailus 

Acked-by: Prabhakar Lad 
> ---
>  Documentation/DocBook/media/v4l/pixfmt-srggb10.xml |    2 +-
>  .../DocBook/media/v4l/pixfmt-srggb10dpcm8.xml      |   29
> 
>  Documentation/DocBook/media/v4l/pixfmt.xml         |    1 +
>  include/linux/videodev2.h                          |    3 ++
>  4 files changed, 34 insertions(+), 1 deletions(-)
>  create mode 100644
> Documentation/DocBook/media/v4l/pixfmt-srggb10dpcm8.xml
>
> diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10.xml
> b/Documentation/DocBook/media/v4l/pixfmt-srggb10.xml
> index 7b27409..c1c62a9 100644
> --- a/Documentation/DocBook/media/v4l/pixfmt-srggb10.xml
> +++ b/Documentation/DocBook/media/v4l/pixfmt-srggb10.xml
> @@ -1,4 +1,4 @@
> -    
> +    
>       
>        V4L2_PIX_FMT_SRGGB10 ('RG10'),
>         V4L2_PIX_FMT_SGRBG10 ('BA10'),
> diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10dpcm8.xml
> b/Documentation/DocBook/media/v4l/pixfmt-srggb10dpcm8.xml
> new file mode 100644
> index 000..5b2b03c
> --- /dev/null
> +++ b/Documentation/DocBook/media/v4l/pixfmt-srggb10dpcm8.xml
> @@ -0,0 +1,29 @@
> +    
> +      
> +       
> +        V4L2_PIX_FMT_SBGGR10DPCM8 ('bBA8'),
> +        V4L2_PIX_FMT_SGBRG10DPCM8 ('bGA8'),
> +        V4L2_PIX_FMT_SGRBG10DPCM8 ('BD10'),
> +        V4L2_PIX_FMT_SRGGB10DPCM8 ('bRA8'),
> +        
> +       &manvol;
> +      
> +      
> +        id="V4L2-PIX-FMT-SBGGR10DPCM8">V4L2_PIX_FMT_SBGGR10DPCM8
> +        id="V4L2-PIX-FMT-SGBRG10DPCM8">V4L2_PIX_FMT_SGBRG10DPCM8
> +        id="V4L2-PIX-FMT-SGRBG10DPCM8">V4L2_PIX_FMT_SGRBG10DPCM8
> +        id="V4L2-PIX-FMT-SRGGB10DPCM8">V4L2_PIX_FMT_SRGGB10DPCM8
> +       10-bit Bayer formats compressed to 8 bits
> +      
> +      
> +       Description
> +
> +       The following four pixel formats are raw sRGB / Bayer
> formats
> +       with 10 bits per colour compressed to 8 bits each, using DPCM
> +       compression. DPCM, differential pulse-code modulation, is lossy.
> +       Each colour component consumes 8 bits of memory. In other respects
> +       this format is similar to  +       linkend="pixfmt-srggb10">.
> +
> +      
> +    
> diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml
> b/Documentation/DocBook/media/v4l/pixfmt.xml
> index 31eaae2..74d4fcd 100644
> --- a/Documentation/DocBook/media/v4l/pixfmt.xml
> +++ b/Documentation/DocBook/media/v4l/pixfmt.xml
> @@ -673,6 +673,7 @@ access the palette, this must be done with ioctls of
> the Linux framebuffer API.<
>     &sub-srggb8;
>     &sub-sbggr16;
>     &sub-srggb10;
> +    &sub-srggb10dpcm8;
>     &sub-srggb12;
>   
>
> diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> index 0805259..dbc0d77 100644
> --- a/include/linux/videodev2.h
> +++ b/include/linux/videodev2.h
> @@ -378,7 +378,10 @@ struct v4l2_pix_format {
>  #define V4L2_PIX_FMT_SGRBG12 v4l2_fourcc('B', 'A', '1', '2') /* 12
>  GRGR.. BGBG.. */
>  #define V4L2_PIX_FMT_SRGGB12 v4l2_fourcc('R', 'G', '1', '2') /* 12
>  RGRG.. GBGB.. */
>        /* 10bit raw bayer DPCM compressed to 8 bits */
> +#define V4L2_PIX_FMT_SBGGR10DPCM8 v4l2_fourcc('b', 'B', 'A', '8')
> +#define V4L2_PIX_FMT_SGBRG10DPCM8 v4l2_fourcc('b', 'G', 'A', '8')
>  #define V4L2_PIX_FMT_SGRBG10DPCM8 v4l2_fourcc('B', 'D', '1', '0')
> +#define V4L2_PIX_FMT_SRGGB10DPCM8 v4l2_fourcc('b', 'R', 'A', '8')
>        /*
>         * 10bit raw bayer, expanded to 16 bits
>         * rrgg ggbb...
> --
> 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

[GIT PULL FOR v3.4 v3] V4L2 subdev and sensor control changes and SMIA++ driver

[Sakari Ailus]

Hi Mauro,

This patchset adds

- Integer menu controls,
- Selection IOCTL for subdevs,
- Sensor control improvements,
- link_validate() media entity and V4L2 subdev pad ops,
- OMAP 3 ISP driver improvements,
- SMIA++ sensor driver and
- Other V4L2 and media improvements (see individual patches)

Changes since pull v2:

- Fixed incorrect 4CC codes in documentation for compresed raw bayer formats

Changes since pull v1:

- Correct selection rectangle field description in subdev selection
  documentation (thanks to Sylwester)
- Use roundup() instead of ALIGN() in SMIA++ driver
- Rebased on current media_tree.git/staging/for_v3.4



The following changes since commit f92c97c8bd77992ff8bd6ef29a23dc82dca799cb:

  [media] update CARDLIST.em28xx (2012-03-19 23:12:02 -0300)

are available in the git repository at:
  ssh://linuxtv.org/git/sailus/media_tree.git media-for-3.4

Jesper Juhl (1):
  adp1653: Remove unneeded include of version.h

Laurent Pinchart (2):
  omap3isp: Prevent pipelines that contain a crashed entity from starting
  omap3isp: Fix frame number propagation

Sakari Ailus (37):
  v4l: Introduce integer menu controls
  v4l: Document integer menu controls
  vivi: Add an integer menu test control
  v4l: VIDIOC_SUBDEV_S_SELECTION and VIDIOC_SUBDEV_G_SELECTION IOCTLs
  v4l: vdev_to_v4l2_subdev() should have return type "struct v4l2_subdev *"
  v4l: Check pad number in get try pointer functions
  v4l: Support s_crop and g_crop through s/g_selection
  v4l: Add subdev selections documentation: svg and dia files
  v4l: Add subdev selections documentation
  v4l: Mark VIDIOC_SUBDEV_G_CROP and VIDIOC_SUBDEV_S_CROP obsolete
  v4l: Image source control class
  v4l: Image processing control class
  v4l: Document raw bayer 4CC codes
  v4l: Add DPCM compressed raw bayer pixel formats
  media: Add link_validate() op to check links to the sink pad
  v4l: Improve sub-device documentation for pad ops
  v4l: Implement v4l2_subdev_link_validate()
  v4l: Allow changing control handler lock
  omap3isp: Support additional in-memory compressed bayer formats
  omap3isp: Move definitions required by board code under include/media.
  omap3: add definition for CONTROL_CAMERA_PHY_CTRL
  omap3isp: Move setting constaints above media_entity_pipeline_start
  omap3isp: Assume media_entity_pipeline_start may fail
  omap3isp: Add lane configuration to platform data
  omap3isp: Collect entities that are part of the pipeline
  omap3isp: Add information on external subdev to struct isp_pipeline
  omap3isp: Introduce isp_video_check_external_subdevs()
  omap3isp: Use external rate instead of vpcfg
  omap3isp: Default link validation for ccp2, csi2, preview and resizer
  omap3isp: Move CCDC link validation to ccdc_link_validate()
  omap3isp: Configure CSI-2 phy based on platform data
  omap3isp: Add resizer data rate configuration to resizer_link_validate
  omap3isp: Find source pad from external entity
  smiapp: Generic SMIA++/SMIA PLL calculator
  smiapp: Add driver
  omap3isp: Prevent crash at module unload
  omap3isp: Handle omap3isp_csi2_reset() errors

 Documentation/DocBook/media/Makefile   |4 +-
 Documentation/DocBook/media/v4l/compat.xml |   19 +-
 Documentation/DocBook/media/v4l/controls.xml   |  168 ++
 Documentation/DocBook/media/v4l/dev-subdev.xml |  202 ++-
 Documentation/DocBook/media/v4l/pixfmt-srggb10.xml |2 +-
 .../DocBook/media/v4l/pixfmt-srggb10dpcm8.xml  |   29 +
 Documentation/DocBook/media/v4l/pixfmt.xml |1 +
 .../media/v4l/subdev-image-processing-crop.dia |  614 +
 .../media/v4l/subdev-image-processing-crop.svg |   63 +
 .../media/v4l/subdev-image-processing-full.dia | 1588 +++
 .../media/v4l/subdev-image-processing-full.svg |  163 ++
 ...ubdev-image-processing-scaling-multi-source.dia | 1152 
 ...ubdev-image-processing-scaling-multi-source.svg |  116 +
 Documentation/DocBook/media/v4l/v4l2.xml   |   20 +-
 .../DocBook/media/v4l/vidioc-g-ext-ctrls.xml   |   12 +
 .../DocBook/media/v4l/vidioc-queryctrl.xml |   39 +-
 .../DocBook/media/v4l/vidioc-subdev-g-crop.xml |9 +-
 .../media/v4l/vidioc-subdev-g-selection.xml|  228 ++
 Documentation/media-framework.txt  |   19 +
 Documentation/video4linux/4CCs.txt |   32 +
 Documentation/video4linux/v4l2-framework.txt   |   21 +
 arch/arm/mach-omap2/control.h  |1 +
 drivers/media/media-entity.c   |   57 +-
 drivers/media/video/Kconfig|3 +
 drivers/media/video/Makefile   |3 +
 drivers/media/video/adp1653.c  |   11 +-
 drivers/media/video/omap3isp/isp.c |   67 +-
 drivers/media/video/omap3isp/isp.h |   11 +-
 drivers/media/vi

[PATCH v5.5 14/40] v4l: Add DPCM compressed raw bayer pixel formats

[Sakari Ailus]

Add three other colour orders for 10-bit to 8-bit DPCM compressed raw bayer
pixel formats.

Signed-off-by: Sakari Ailus 
---
 Documentation/DocBook/media/v4l/pixfmt-srggb10.xml |2 +-
 .../DocBook/media/v4l/pixfmt-srggb10dpcm8.xml  |   29 
 Documentation/DocBook/media/v4l/pixfmt.xml |1 +
 include/linux/videodev2.h  |3 ++
 4 files changed, 34 insertions(+), 1 deletions(-)
 create mode 100644 Documentation/DocBook/media/v4l/pixfmt-srggb10dpcm8.xml

diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10.xml 
b/Documentation/DocBook/media/v4l/pixfmt-srggb10.xml
index 7b27409..c1c62a9 100644
--- a/Documentation/DocBook/media/v4l/pixfmt-srggb10.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt-srggb10.xml
@@ -1,4 +1,4 @@
-
+
   
V4L2_PIX_FMT_SRGGB10 ('RG10'),
 V4L2_PIX_FMT_SGRBG10 ('BA10'),
diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10dpcm8.xml 
b/Documentation/DocBook/media/v4l/pixfmt-srggb10dpcm8.xml
new file mode 100644
index 000..5b2b03c
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-srggb10dpcm8.xml
@@ -0,0 +1,29 @@
+
+  
+   
+V4L2_PIX_FMT_SBGGR10DPCM8 ('bBA8'),
+V4L2_PIX_FMT_SGBRG10DPCM8 ('bGA8'),
+V4L2_PIX_FMT_SGRBG10DPCM8 ('BD10'),
+V4L2_PIX_FMT_SRGGB10DPCM8 ('bRA8'),
+
+   &manvol;
+  
+  
+   V4L2_PIX_FMT_SBGGR10DPCM8
+   V4L2_PIX_FMT_SGBRG10DPCM8
+   V4L2_PIX_FMT_SGRBG10DPCM8
+   V4L2_PIX_FMT_SRGGB10DPCM8
+   10-bit Bayer formats compressed to 8 bits
+  
+  
+   Description
+
+   The following four pixel formats are raw sRGB / Bayer formats
+   with 10 bits per colour compressed to 8 bits each, using DPCM
+   compression. DPCM, differential pulse-code modulation, is lossy.
+   Each colour component consumes 8 bits of memory. In other respects
+   this format is similar to .
+
+  
+
diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml 
b/Documentation/DocBook/media/v4l/pixfmt.xml
index 31eaae2..74d4fcd 100644
--- a/Documentation/DocBook/media/v4l/pixfmt.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt.xml
@@ -673,6 +673,7 @@ access the palette, this must be done with ioctls of the 
Linux framebuffer API.<
 &sub-srggb8;
 &sub-sbggr16;
 &sub-srggb10;
+&sub-srggb10dpcm8;
 &sub-srggb12;
   
 
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 0805259..dbc0d77 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -378,7 +378,10 @@ struct v4l2_pix_format {
 #define V4L2_PIX_FMT_SGRBG12 v4l2_fourcc('B', 'A', '1', '2') /* 12  GRGR.. 
BGBG.. */
 #define V4L2_PIX_FMT_SRGGB12 v4l2_fourcc('R', 'G', '1', '2') /* 12  RGRG.. 
GBGB.. */
/* 10bit raw bayer DPCM compressed to 8 bits */
+#define V4L2_PIX_FMT_SBGGR10DPCM8 v4l2_fourcc('b', 'B', 'A', '8')
+#define V4L2_PIX_FMT_SGBRG10DPCM8 v4l2_fourcc('b', 'G', 'A', '8')
 #define V4L2_PIX_FMT_SGRBG10DPCM8 v4l2_fourcc('B', 'D', '1', '0')
+#define V4L2_PIX_FMT_SRGGB10DPCM8 v4l2_fourcc('b', 'R', 'A', '8')
/*
 * 10bit raw bayer, expanded to 16 bits
 * rrgg ggbb...
-- 
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

[PATCH v2 10/9] sh_mobile_ceu_camera: Support user-configurable line stride

[Laurent Pinchart]

In image mode, the CEU allows configurable line strides up to 8188
pixels.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/video/sh_mobile_ceu_camera.c |   25 +
 1 files changed, 17 insertions(+), 8 deletions(-)

Hi Guennadi,

This patch was missing from my "soc-camera: Add support for configurable line
stride" series. It applies on top of the other 9 patches. Sorry about that.

diff --git a/drivers/media/video/sh_mobile_ceu_camera.c 
b/drivers/media/video/sh_mobile_ceu_camera.c
index b8801bd..6d96136 100644
--- a/drivers/media/video/sh_mobile_ceu_camera.c
+++ b/drivers/media/video/sh_mobile_ceu_camera.c
@@ -338,19 +338,15 @@ static int sh_mobile_ceu_capture(struct sh_mobile_ceu_dev 
*pcdev)
 
ceu_write(pcdev, top1, phys_addr_top);
if (V4L2_FIELD_NONE != pcdev->field) {
-   if (planar)
-   phys_addr_bottom = phys_addr_top + icd->user_width;
-   else
-   phys_addr_bottom = phys_addr_top + icd->bytesperline;
+   phys_addr_bottom = phys_addr_top + icd->bytesperline;
ceu_write(pcdev, bottom1, phys_addr_bottom);
}
 
if (planar) {
-   phys_addr_top += icd->user_width *
-   icd->user_height;
+   phys_addr_top += icd->bytesperline * icd->user_height;
ceu_write(pcdev, top2, phys_addr_top);
if (V4L2_FIELD_NONE != pcdev->field) {
-   phys_addr_bottom = phys_addr_top + icd->user_width;
+   phys_addr_bottom = phys_addr_top + icd->bytesperline;
ceu_write(pcdev, bottom2, phys_addr_bottom);
}
}
@@ -677,7 +673,7 @@ static void sh_mobile_ceu_set_rect(struct soc_camera_device 
*icd)
in_width *= 2;
left_offset *= 2;
}
-   cdwdr_width = width;
+   cdwdr_width = icd->bytesperline;
} else {
int bytes_per_line = soc_mbus_bytes_per_line(width,
icd->current_fmt->host_fmt);
@@ -1834,6 +1830,8 @@ static int sh_mobile_ceu_set_fmt(struct soc_camera_device 
*icd,
return 0;
 }
 
+#define CEU_CHDW_MAX   8188U   /* Maximum line stride */
+
 static int sh_mobile_ceu_try_fmt(struct soc_camera_device *icd,
 struct v4l2_format *f)
 {
@@ -1910,10 +1908,20 @@ static int sh_mobile_ceu_try_fmt(struct 
soc_camera_device *icd,
pix->width = width;
if (mf.height > height)
pix->height = height;
+
+   pix->bytesperline = max(pix->bytesperline, pix->width);
+   pix->bytesperline = min(pix->bytesperline, CEU_CHDW_MAX);
+   pix->bytesperline &= ~3;
+   break;
+
+   default:
+   /* Configurable stride isn't supported in pass-through mode. */
+   pix->bytesperline  = 0;
}
 
pix->width  &= ~3;
pix->height &= ~3;
+   pix->sizeimage  = 0;
 
dev_geo(icd->parent, "%s(): return %d, fmt 0x%x, %ux%u\n",
__func__, ret, pix->pixelformat, pix->width, pix->height);
@@ -2129,6 +2137,7 @@ static int __devinit sh_mobile_ceu_probe(struct 
platform_device *pdev)
pcdev->ici.nr = pdev->id;
pcdev->ici.drv_name = dev_name(&pdev->dev);
pcdev->ici.ops = &sh_mobile_ceu_host_ops;
+   pcdev->ici.capabilities = SOCAM_HOST_CAP_STRIDE;
 
pcdev->alloc_ctx = vb2_dma_contig_init_ctx(&pdev->dev);
if (IS_ERR(pcdev->alloc_ctx)) {
-- 
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] media: vb2-memops: Export vb2_get_vma symbol

[Laurent Pinchart]

Hi Tomasz,

On Monday 23 January 2012 15:44:25 Tomasz Stanislawski wrote:
> Hi Laurent,
> 
> Thank you for finding a bug in vb2-core.

You're welcome.

Could you please take the patch in your tree ?

> On 01/23/2012 03:35 PM, Laurent Pinchart wrote:
> > The vb2_get_vma() function is called by videobuf2-dma-contig. Export it.
> > 
> > Signed-off-by: Laurent Pinchart
> > ---
> > 
> >   drivers/media/video/videobuf2-memops.c |1 +
> >   1 files changed, 1 insertions(+), 0 deletions(-)
> > 
> > Hi Thomas,
> > 
> > The following patch is needed to compile videobuf2-dma-contig as a module.
> > 
> > diff --git a/drivers/media/video/videobuf2-memops.c
> > b/drivers/media/video/videobuf2-memops.c index 71a7a78..718f70e 100644
> > --- a/drivers/media/video/videobuf2-memops.c
> > +++ b/drivers/media/video/videobuf2-memops.c
> > @@ -55,6 +55,7 @@ struct vm_area_struct *vb2_get_vma(struct vm_area_struct
> > *vma)> 
> > return vma_copy;
> >   
> >   }
> > 
> > +EXPORT_SYMBOL_GPL(vb2_get_vma);
> > 
> >   /**
> >   
> >* vb2_put_userptr() - release a userspace virtual memory area

-- 
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 1/2] V4L: sh_mobile_ceu_camera: maximum image size depends on the hardware version

[Laurent Pinchart]

Hi Guennadi,

On Wednesday 21 March 2012 11:59:59 Guennadi Liakhovetski wrote:
> On Wed, 21 Mar 2012, Laurent Pinchart wrote:
> > On Wednesday 14 March 2012 16:02:20 Guennadi Liakhovetski wrote:
> > > Newer CEU versions, e.g., the one, used on sh7372, support image sizes
> > > larger than 2560x1920. Retrieve maximum sizes from platform properties.
> > 
> > Isn't there a way you could query the CEU version at runtime instead ?
> 
> I'm not aware of any. And even if it were possible, I'm not sure putting
> tables with "version - feature-set" tables into the driver proper would be
> a very good idea. It used to be like that (or almost like that with
> dependencies on the chip-type) in other drivers (e.g., shdma) and we
> dropped it in favour of platform data.

I would have voted for doing it the other way around. The driver should know 
about the different hardware versions it supports. Putting that in platform 
data just moves the burden to board code developers and duplicates the 
information in lots of places. At worse, if you can't detect the version at 
runtime, I would put a version field in the platform data and map that to 
hardware features in the driver.

-- 
Regards,

Laurent Pinchart

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

[PATCH v2 2/9] soc_camera: Use soc_camera_device::sizeimage to compute buffer sizes

[Laurent Pinchart]

Instead of computing the buffer size manually in the videobuf queue
setup and buffer prepare callbacks, use the previously negotiated
soc_camera_device::sizeimage value.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/video/atmel-isi.c|   17 +++--
 drivers/media/video/mx1_camera.c   |   14 ++
 drivers/media/video/mx2_camera.c   |   14 ++
 drivers/media/video/mx3_camera.c   |   20 +---
 drivers/media/video/omap1_camera.c |   14 ++
 drivers/media/video/pxa_camera.c   |   14 ++
 drivers/media/video/sh_mobile_ceu_camera.c |   25 +
 7 files changed, 29 insertions(+), 89 deletions(-)

diff --git a/drivers/media/video/atmel-isi.c b/drivers/media/video/atmel-isi.c
index ec3f6a0..d58491b 100644
--- a/drivers/media/video/atmel-isi.c
+++ b/drivers/media/video/atmel-isi.c
@@ -260,7 +260,7 @@ static int queue_setup(struct vb2_queue *vq, const struct 
v4l2_format *fmt,
struct soc_camera_host *ici = to_soc_camera_host(icd->parent);
struct atmel_isi *isi = ici->priv;
unsigned long size;
-   int ret, bytes_per_line;
+   int ret;
 
/* Reset ISI */
ret = atmel_isi_wait_status(isi, WAIT_ISI_RESET);
@@ -271,13 +271,7 @@ static int queue_setup(struct vb2_queue *vq, const struct 
v4l2_format *fmt,
/* Disable all interrupts */
isi_writel(isi, ISI_INTDIS, ~0UL);
 
-   bytes_per_line = soc_mbus_bytes_per_line(icd->user_width,
-   icd->current_fmt->host_fmt);
-
-   if (bytes_per_line < 0)
-   return bytes_per_line;
-
-   size = bytes_per_line * icd->user_height;
+   size = icd->sizeimage;
 
if (!*nbuffers || *nbuffers > MAX_BUFFER_NUM)
*nbuffers = MAX_BUFFER_NUM;
@@ -316,13 +310,8 @@ static int buffer_prepare(struct vb2_buffer *vb)
struct atmel_isi *isi = ici->priv;
unsigned long size;
struct isi_dma_desc *desc;
-   int bytes_per_line = soc_mbus_bytes_per_line(icd->user_width,
-   icd->current_fmt->host_fmt);
-
-   if (bytes_per_line < 0)
-   return bytes_per_line;
 
-   size = bytes_per_line * icd->user_height;
+   size = icd->sizeimage;
 
if (vb2_plane_size(vb, 0) < size) {
dev_err(icd->parent, "%s data will not fit into plane (%lu < 
%lu)\n",
diff --git a/drivers/media/video/mx1_camera.c b/drivers/media/video/mx1_camera.c
index 055d11d..4296a83 100644
--- a/drivers/media/video/mx1_camera.c
+++ b/drivers/media/video/mx1_camera.c
@@ -126,13 +126,8 @@ static int mx1_videobuf_setup(struct videobuf_queue *vq, 
unsigned int *count,
  unsigned int *size)
 {
struct soc_camera_device *icd = vq->priv_data;
-   int bytes_per_line = soc_mbus_bytes_per_line(icd->user_width,
-   icd->current_fmt->host_fmt);
 
-   if (bytes_per_line < 0)
-   return bytes_per_line;
-
-   *size = bytes_per_line * icd->user_height;
+   *size = icd->sizeimage;
 
if (!*count)
*count = 32;
@@ -171,11 +166,6 @@ static int mx1_videobuf_prepare(struct videobuf_queue *vq,
struct soc_camera_device *icd = vq->priv_data;
struct mx1_buffer *buf = container_of(vb, struct mx1_buffer, vb);
int ret;
-   int bytes_per_line = soc_mbus_bytes_per_line(icd->user_width,
-   icd->current_fmt->host_fmt);
-
-   if (bytes_per_line < 0)
-   return bytes_per_line;
 
dev_dbg(icd->parent, "%s (vb=0x%p) 0x%08lx %d\n", __func__,
vb, vb->baddr, vb->bsize);
@@ -202,7 +192,7 @@ static int mx1_videobuf_prepare(struct videobuf_queue *vq,
vb->state   = VIDEOBUF_NEEDS_INIT;
}
 
-   vb->size = bytes_per_line * vb->height;
+   vb->size = icd->sizeimage;
if (0 != vb->baddr && vb->bsize < vb->size) {
ret = -EINVAL;
goto out;
diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index 77f8dde..091f2e1 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -505,15 +505,10 @@ static int mx2_videobuf_setup(struct videobuf_queue *vq, 
unsigned int *count,
  unsigned int *size)
 {
struct soc_camera_device *icd = vq->priv_data;
-   int bytes_per_line = soc_mbus_bytes_per_line(icd->user_width,
-   icd->current_fmt->host_fmt);
 
dev_dbg(icd->parent, "count=%d, size=%d\n", *count, *size);
 
-   if (bytes_per_line < 0)
-   return bytes_per_line;
-
-   *size = bytes_per_line * icd->user_height;
+   *size = icd->sizeimage;
 
if (0 == *count)
*count = 32;
@@ -548,16 +543,11 @@ static int mx2_videobuf_pre

[PATCH v2 3/9] soc_camera: Use soc_camera_device::bytesperline to compute line sizes

[Laurent Pinchart]

Instead of computing the line sizes, use the previously negotiated
soc_camera_device::bytesperline value.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/video/mx3_camera.c   |7 ++-
 drivers/media/video/sh_mobile_ceu_camera.c |4 +---
 2 files changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/media/video/mx3_camera.c b/drivers/media/video/mx3_camera.c
index f8ce875..66d9a24 100644
--- a/drivers/media/video/mx3_camera.c
+++ b/drivers/media/video/mx3_camera.c
@@ -265,13 +265,10 @@ static void mx3_videobuf_queue(struct vb2_buffer *vb)
struct idmac_channel *ichan = mx3_cam->idmac_channel[0];
struct idmac_video_param *video = &ichan->params.video;
const struct soc_mbus_pixelfmt *host_fmt = icd->current_fmt->host_fmt;
-   int bytes_per_line = soc_mbus_bytes_per_line(icd->user_width, host_fmt);
unsigned long flags;
dma_cookie_t cookie;
size_t new_size;
 
-   BUG_ON(bytes_per_line <= 0);
-
new_size = icd->sizeimage;
 
if (vb2_plane_size(vb, 0) < new_size) {
@@ -312,9 +309,9 @@ static void mx3_videobuf_queue(struct vb2_buffer *vb)
 * horizontal parameters in this case are expressed in bytes,
 * not in pixels.
 */
-   video->out_width= bytes_per_line;
+   video->out_width= icd->bytesperline;
video->out_height   = icd->user_height;
-   video->out_stride   = bytes_per_line;
+   video->out_stride   = icd->bytesperline;
} else {
/*
 * For IPU known formats the pixel unit will be managed
diff --git a/drivers/media/video/sh_mobile_ceu_camera.c 
b/drivers/media/video/sh_mobile_ceu_camera.c
index f5aa369..932ed5e 100644
--- a/drivers/media/video/sh_mobile_ceu_camera.c
+++ b/drivers/media/video/sh_mobile_ceu_camera.c
@@ -333,9 +333,7 @@ static int sh_mobile_ceu_capture(struct sh_mobile_ceu_dev 
*pcdev)
if (planar)
phys_addr_bottom = phys_addr_top + icd->user_width;
else
-   phys_addr_bottom = phys_addr_top +
-   soc_mbus_bytes_per_line(icd->user_width,
-   
icd->current_fmt->host_fmt);
+   phys_addr_bottom = phys_addr_top + icd->bytesperline;
ceu_write(pcdev, bottom1, phys_addr_bottom);
}
 
-- 
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

[PATCH v2 9/9] soc-camera: Support user-configurable line stride

[Laurent Pinchart]

Add a capabilities field to the soc_camera_host structure to flag hosts
that support user-configurable line strides. soc_camera_try_fmt() then
passes the user-provided bytesperline and sizeimage format fields to
such hosts, and expects the host to check (and fix if needed) the
values.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/video/mx2_camera.c |2 ++
 drivers/media/video/soc_camera.c |6 --
 include/media/soc_camera.h   |4 
 3 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index 1269b5f..253232e 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -1626,6 +1626,8 @@ static int __devinit mx2_camera_probe(struct 
platform_device *pdev)
pcdev->soc_host.priv= pcdev;
pcdev->soc_host.v4l2_dev.dev= &pdev->dev;
pcdev->soc_host.nr  = pdev->id;
+   if (cpu_is_mx25()) {
+   pcdev->soc_host.capabilities = SOCAM_HOST_CAP_STRIDE;
err = soc_camera_host_register(&pcdev->soc_host);
if (err)
goto exit_free_emma;
diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index 02ae98b..04a5fcab 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -171,8 +171,10 @@ static int soc_camera_try_fmt(struct soc_camera_device 
*icd,
dev_dbg(icd->pdev, "TRY_FMT(%c%c%c%c, %ux%u)\n",
pixfmtstr(pix->pixelformat), pix->width, pix->height);
 
-   pix->bytesperline = 0;
-   pix->sizeimage = 0;
+   if (!(ici->capabilities & SOCAM_HOST_CAP_STRIDE)) {
+   pix->bytesperline = 0;
+   pix->sizeimage = 0;
+   }
 
ret = ici->ops->try_fmt(icd, f);
if (ret < 0)
diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
index b5c2b6c..9eee641 100644
--- a/include/media/soc_camera.h
+++ b/include/media/soc_camera.h
@@ -56,10 +56,14 @@ struct soc_camera_device {
};
 };
 
+/* Host supports programmable stride */
+#define SOCAM_HOST_CAP_STRIDE  (1 << 0)
+
 struct soc_camera_host {
struct v4l2_device v4l2_dev;
struct list_head list;
unsigned char nr;   /* Host number */
+   u32 capabilities;
void *priv;
const char *drv_name;
struct soc_camera_host_ops *ops;
-- 
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

[PATCH v2 8/9] mx2_camera: Use soc_mbus_image_size() instead of manual computation

[Laurent Pinchart]

Use the new soc_mbus_image_size() function to compute the image size.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/video/mx2_camera.c |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index 091f2e1..1269b5f 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -1121,7 +1121,8 @@ static int mx2_camera_try_fmt(struct soc_camera_device 
*icd,
xlate->host_fmt);
if (pix->bytesperline < 0)
return pix->bytesperline;
-   pix->sizeimage = pix->height * pix->bytesperline;
+   pix->sizeimage = soc_mbus_image_size(xlate->host_fmt,
+   pix->bytesperline, pix->height);
/* Check against the CSIRXCNT limit */
if (pix->sizeimage > 4 * 0x3) {
/* Adjust geometry, preserve aspect ratio */
@@ -1132,7 +1133,8 @@ static int mx2_camera_try_fmt(struct soc_camera_device 
*icd,
pix->bytesperline = soc_mbus_bytes_per_line(pix->width,
xlate->host_fmt);
BUG_ON(pix->bytesperline < 0);
-   pix->sizeimage = pix->height * pix->bytesperline;
+   pix->sizeimage = soc_mbus_image_size(xlate->host_fmt,
+   pix->bytesperline, pix->height);
}
}
 
-- 
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

[PATCH v2 7/9] soc-camera: Honor user-requested bytesperline and sizeimage

[Laurent Pinchart]

Compute the bytesperline and sizeimage values when trying/setting
formats or when allocating buffers by taking the user-requested values
into account.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/video/mx3_camera.c   |   20 +-
 drivers/media/video/sh_mobile_ceu_camera.c |   20 +-
 drivers/media/video/soc_camera.c   |   29 ++-
 3 files changed, 43 insertions(+), 26 deletions(-)

diff --git a/drivers/media/video/mx3_camera.c b/drivers/media/video/mx3_camera.c
index 84579b6..a0c7d65 100644
--- a/drivers/media/video/mx3_camera.c
+++ b/drivers/media/video/mx3_camera.c
@@ -206,17 +206,25 @@ static int mx3_videobuf_setup(struct vb2_queue *vq,
if (fmt) {
const struct soc_camera_format_xlate *xlate = 
soc_camera_xlate_by_fourcc(icd,

fmt->fmt.pix.pixelformat);
-   int bytes_per_line;
+   unsigned int bytes_per_line;
+   int ret;
 
if (!xlate)
return -EINVAL;
 
-   bytes_per_line = soc_mbus_bytes_per_line(fmt->fmt.pix.width,
-xlate->host_fmt);
-   if (bytes_per_line < 0)
-   return bytes_per_line;
+   ret = soc_mbus_bytes_per_line(fmt->fmt.pix.width,
+ xlate->host_fmt);
+   if (ret < 0)
+   return ret;
+
+   bytes_per_line = max_t(u32, fmt->fmt.pix.bytesperline, ret);
+
+   ret = soc_mbus_image_size(xlate->host_fmt, bytes_per_line,
+ fmt->fmt.pix.height);
+   if (ret < 0)
+   return ret;
 
-   sizes[0] = bytes_per_line * fmt->fmt.pix.height;
+   sizes[0] = max_t(u32, fmt->fmt.pix.sizeimage, ret);
} else {
/* Called from VIDIOC_REQBUFS or in compatibility mode */
sizes[0] = icd->sizeimage;
diff --git a/drivers/media/video/sh_mobile_ceu_camera.c 
b/drivers/media/video/sh_mobile_ceu_camera.c
index 0cc04d9..b8801bd 100644
--- a/drivers/media/video/sh_mobile_ceu_camera.c
+++ b/drivers/media/video/sh_mobile_ceu_camera.c
@@ -210,17 +210,25 @@ static int sh_mobile_ceu_videobuf_setup(struct vb2_queue 
*vq,
if (fmt) {
const struct soc_camera_format_xlate *xlate = 
soc_camera_xlate_by_fourcc(icd,

fmt->fmt.pix.pixelformat);
-   int bytes_per_line;
+   unsigned int bytes_per_line;
+   int ret;
 
if (!xlate)
return -EINVAL;
 
-   bytes_per_line = soc_mbus_bytes_per_line(fmt->fmt.pix.width,
-xlate->host_fmt);
-   if (bytes_per_line < 0)
-   return bytes_per_line;
+   ret = soc_mbus_bytes_per_line(fmt->fmt.pix.width,
+ xlate->host_fmt);
+   if (ret < 0)
+   return ret;
+
+   bytes_per_line = max_t(u32, fmt->fmt.pix.bytesperline, ret);
+
+   ret = soc_mbus_image_size(xlate->host_fmt, bytes_per_line,
+ fmt->fmt.pix.height);
+   if (ret < 0)
+   return ret;
 
-   sizes[0] = bytes_per_line * fmt->fmt.pix.height;
+   sizes[0] = max_t(u32, fmt->fmt.pix.sizeimage, ret);
} else {
/* Called from VIDIOC_REQBUFS or in compatibility mode */
sizes[0] = icd->sizeimage;
diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index b827107..02ae98b 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -164,6 +164,7 @@ static int soc_camera_try_fmt(struct soc_camera_device *icd,
  struct v4l2_format *f)
 {
struct soc_camera_host *ici = to_soc_camera_host(icd->parent);
+   const struct soc_camera_format_xlate *xlate;
struct v4l2_pix_format *pix = &f->fmt.pix;
int ret;
 
@@ -177,22 +178,22 @@ static int soc_camera_try_fmt(struct soc_camera_device 
*icd,
if (ret < 0)
return ret;
 
-   if (!pix->sizeimage) {
-   if (!pix->bytesperline) {
-   const struct soc_camera_format_xlate *xlate;
+   xlate = soc_camera_xlate_by_fourcc(icd, pix->pixelformat);
+   if (!xlate)
+   return -EINVAL;
 
-   xlate = soc_camera_xlate_by_fourcc(icd, 
pix->pixelformat);
-   if (!xlate)
-   return -EINVAL;
+   ret = soc_mbus_bytes_per_line(pix->width, xlate->host_fmt);
+   if (ret < 0)
+   return ret;
 
-  

[PATCH v2 1/9] mx2_camera: Fix sizeimage computation in try_fmt()

[Laurent Pinchart]

The try_fmt() handler restricts the image width based on the hardware
limits and updates the bytesperline value, but doesn't update sizeimage.
Fix it.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/video/mx2_camera.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index 04aab0c..77f8dde 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -1142,6 +1142,7 @@ static int mx2_camera_try_fmt(struct soc_camera_device 
*icd,
pix->bytesperline = soc_mbus_bytes_per_line(pix->width,
xlate->host_fmt);
BUG_ON(pix->bytesperline < 0);
+   pix->sizeimage = pix->height * pix->bytesperline;
}
}
 
-- 
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

[PATCH v2 6/9] soc-camera: Add soc_mbus_image_size

[Laurent Pinchart]

The function returns the minimum size of an image for a given number of
bytes per line (as per the V4L2 specification), width and format.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/video/soc_mediabus.c |   18 ++
 include/media/soc_mediabus.h   |2 ++
 2 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/soc_mediabus.c 
b/drivers/media/video/soc_mediabus.c
index a707314..89dce09 100644
--- a/drivers/media/video/soc_mediabus.c
+++ b/drivers/media/video/soc_mediabus.c
@@ -397,6 +397,24 @@ s32 soc_mbus_bytes_per_line(u32 width, const struct 
soc_mbus_pixelfmt *mf)
 }
 EXPORT_SYMBOL(soc_mbus_bytes_per_line);
 
+s32 soc_mbus_image_size(const struct soc_mbus_pixelfmt *mf,
+   u32 bytes_per_line, u32 height)
+{
+   if (mf->layout == SOC_MBUS_LAYOUT_PACKED)
+   return bytes_per_line * height;
+
+   switch (mf->packing) {
+   case SOC_MBUS_PACKING_2X8_PADHI:
+   case SOC_MBUS_PACKING_2X8_PADLO:
+   return bytes_per_line * height * 2;
+   case SOC_MBUS_PACKING_1_5X8:
+   return bytes_per_line * height * 3 / 2;
+   default:
+   return -EINVAL;
+   }
+}
+EXPORT_SYMBOL(soc_mbus_image_size);
+
 const struct soc_mbus_pixelfmt *soc_mbus_find_fmtdesc(
enum v4l2_mbus_pixelcode code,
const struct soc_mbus_lookup *lookup,
diff --git a/include/media/soc_mediabus.h b/include/media/soc_mediabus.h
index e18eed4..0dc6f46 100644
--- a/include/media/soc_mediabus.h
+++ b/include/media/soc_mediabus.h
@@ -99,6 +99,8 @@ const struct soc_mbus_pixelfmt *soc_mbus_find_fmtdesc(
 const struct soc_mbus_pixelfmt *soc_mbus_get_fmtdesc(
enum v4l2_mbus_pixelcode code);
 s32 soc_mbus_bytes_per_line(u32 width, const struct soc_mbus_pixelfmt *mf);
+s32 soc_mbus_image_size(const struct soc_mbus_pixelfmt *mf,
+   u32 bytes_per_line, u32 height);
 int soc_mbus_samples_per_pixel(const struct soc_mbus_pixelfmt *mf,
unsigned int *numerator, unsigned int *denominator);
 unsigned int soc_mbus_config_compatible(const struct v4l2_mbus_config *cfg,
-- 
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

[PATCH v2 5/9] soc-camera: Fix bytes per line computation for planar formats

[Laurent Pinchart]

The V4L2 specification defines bytesperline for planar formats as the
number of bytes per line for the largest plane. Modify
soc_mbus_bytes_per_line() accordingly.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/video/soc_mediabus.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/soc_mediabus.c 
b/drivers/media/video/soc_mediabus.c
index 44dba6c..a707314 100644
--- a/drivers/media/video/soc_mediabus.c
+++ b/drivers/media/video/soc_mediabus.c
@@ -378,6 +378,9 @@ EXPORT_SYMBOL(soc_mbus_samples_per_pixel);
 
 s32 soc_mbus_bytes_per_line(u32 width, const struct soc_mbus_pixelfmt *mf)
 {
+   if (mf->layout != SOC_MBUS_LAYOUT_PACKED)
+   return width * mf->bits_per_sample / 8;
+
switch (mf->packing) {
case SOC_MBUS_PACKING_NONE:
return width * mf->bits_per_sample / 8;
-- 
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

[PATCH v2 4/9] soc-camera: Add plane layout information to struct soc_mbus_pixelfmt

[Laurent Pinchart]

To compute the value of the v4l2_pix_format::bytesperline field, we need
information about planes layout for planar formats. The new enum
soc_mbus_layout conveys that information.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/video/atmel-isi.c|1 +
 drivers/media/video/mx3_camera.c   |2 +
 drivers/media/video/omap1_camera.c |8 ++
 drivers/media/video/pxa_camera.c   |1 +
 drivers/media/video/sh_mobile_ceu_camera.c |4 +++
 drivers/media/video/soc_mediabus.c |   33 
 include/media/soc_mediabus.h   |   19 
 7 files changed, 68 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/atmel-isi.c b/drivers/media/video/atmel-isi.c
index d58491b..6274a91 100644
--- a/drivers/media/video/atmel-isi.c
+++ b/drivers/media/video/atmel-isi.c
@@ -627,6 +627,7 @@ static const struct soc_mbus_pixelfmt isi_camera_formats[] 
= {
.bits_per_sample= 8,
.packing= SOC_MBUS_PACKING_2X8_PADHI,
.order  = SOC_MBUS_ORDER_LE,
+   .layout = SOC_MBUS_LAYOUT_PACKED,
},
 };
 
diff --git a/drivers/media/video/mx3_camera.c b/drivers/media/video/mx3_camera.c
index 66d9a24..84579b6 100644
--- a/drivers/media/video/mx3_camera.c
+++ b/drivers/media/video/mx3_camera.c
@@ -637,12 +637,14 @@ static const struct soc_mbus_pixelfmt 
mx3_camera_formats[] = {
.bits_per_sample= 8,
.packing= SOC_MBUS_PACKING_NONE,
.order  = SOC_MBUS_ORDER_LE,
+   .layout = SOC_MBUS_LAYOUT_PACKED,
}, {
.fourcc = V4L2_PIX_FMT_GREY,
.name   = "Monochrome 8 bit",
.bits_per_sample= 8,
.packing= SOC_MBUS_PACKING_NONE,
.order  = SOC_MBUS_ORDER_LE,
+   .layout = SOC_MBUS_LAYOUT_PACKED,
},
 };
 
diff --git a/drivers/media/video/omap1_camera.c 
b/drivers/media/video/omap1_camera.c
index addab76..c7e4114 100644
--- a/drivers/media/video/omap1_camera.c
+++ b/drivers/media/video/omap1_camera.c
@@ -989,6 +989,7 @@ static const struct soc_mbus_lookup omap1_cam_formats[] = {
.bits_per_sample= 8,
.packing= SOC_MBUS_PACKING_2X8_PADHI,
.order  = SOC_MBUS_ORDER_BE,
+   .layout = SOC_MBUS_LAYOUT_PACKED,
},
 }, {
.code = V4L2_MBUS_FMT_VYUY8_2X8,
@@ -998,6 +999,7 @@ static const struct soc_mbus_lookup omap1_cam_formats[] = {
.bits_per_sample= 8,
.packing= SOC_MBUS_PACKING_2X8_PADHI,
.order  = SOC_MBUS_ORDER_BE,
+   .layout = SOC_MBUS_LAYOUT_PACKED,
},
 }, {
.code = V4L2_MBUS_FMT_YUYV8_2X8,
@@ -1007,6 +1009,7 @@ static const struct soc_mbus_lookup omap1_cam_formats[] = 
{
.bits_per_sample= 8,
.packing= SOC_MBUS_PACKING_2X8_PADHI,
.order  = SOC_MBUS_ORDER_BE,
+   .layout = SOC_MBUS_LAYOUT_PACKED,
},
 }, {
.code = V4L2_MBUS_FMT_YVYU8_2X8,
@@ -1016,6 +1019,7 @@ static const struct soc_mbus_lookup omap1_cam_formats[] = 
{
.bits_per_sample= 8,
.packing= SOC_MBUS_PACKING_2X8_PADHI,
.order  = SOC_MBUS_ORDER_BE,
+   .layout = SOC_MBUS_LAYOUT_PACKED,
},
 }, {
.code = V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE,
@@ -1025,6 +1029,7 @@ static const struct soc_mbus_lookup omap1_cam_formats[] = 
{
.bits_per_sample= 8,
.packing= SOC_MBUS_PACKING_2X8_PADHI,
.order  = SOC_MBUS_ORDER_BE,
+   .layout = SOC_MBUS_LAYOUT_PACKED,
},
 }, {
.code = V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE,
@@ -1034,6 +1039,7 @@ static const struct soc_mbus_lookup omap1_cam_formats[] = 
{
.bits_per_sample= 8,
.packing= SOC_MBUS_PACKING_2X8_PADHI,
.order  = SOC_MBUS_ORDER_BE,
+   .layout = SOC_MBUS_LAYOUT_PACKED,
},
 }, {
.code = V4L2_MBUS_FMT_RGB565_2X8_BE,
@@ -1043,6 +1049,7 @@ static const struct soc_mbus_lookup omap1_cam_formats[] = 
{
.bits_per_sample= 8,
.packing= SOC_MBUS_PACKING_2X8_PADHI,
.order  = SOC_MBUS_ORDER_BE,
+   .layout = SOC_MBUS_LAYOUT_PACKED,
},
 }, {
.code = V4L2_MB

[PATCH v2 0/9] soc-camera: Add support for configurable line stride

[Laurent Pinchart]

Hi Guennadi,

Here's the second version of the soc-camera configurable line stride support
patches.

The patches have been successfully tested on a Mackerel board with the on-board
VGA sensor.

Laurent Pinchart (9):
  mx2_camera: Fix sizeimage computation in try_fmt()
  soc_camera: Use soc_camera_device::sizeimage to compute buffer sizes
  soc_camera: Use soc_camera_device::bytesperline to compute line sizes
  soc-camera: Add plane layout information to struct soc_mbus_pixelfmt
  soc-camera: Fix bytes per line computation for planar formats
  soc-camera: Add soc_mbus_image_size
  soc-camera: Honor user-requested bytesperline and sizeimage
  mx2_camera: Use soc_mbus_image_size() instead of manual computation
  soc-camera: Support user-configurable line stride

 drivers/media/video/atmel-isi.c|   18 ++---
 drivers/media/video/mx1_camera.c   |   14 +--
 drivers/media/video/mx2_camera.c   |   21 ---
 drivers/media/video/mx3_camera.c   |   41 -
 drivers/media/video/omap1_camera.c |   22 +--
 drivers/media/video/pxa_camera.c   |   15 ++--
 drivers/media/video/sh_mobile_ceu_camera.c |   45 ---
 drivers/media/video/soc_camera.c   |   35 ++
 drivers/media/video/soc_mediabus.c |   54 
 include/media/soc_camera.h |4 ++
 include/media/soc_mediabus.h   |   21 +++
 11 files changed, 172 insertions(+), 118 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: [PATCH 1/2] V4L: sh_mobile_ceu_camera: maximum image size depends on the hardware version

[Guennadi Liakhovetski]

Hi Laurent

On Wed, 21 Mar 2012, Laurent Pinchart wrote:

> Hi Guennadi,
> 
> On Wednesday 14 March 2012 16:02:20 Guennadi Liakhovetski wrote:
> > Newer CEU versions, e.g., the one, used on sh7372, support image sizes
> > larger than 2560x1920. Retrieve maximum sizes from platform properties.
> 
> Isn't there a way you could query the CEU version at runtime instead ?

I'm not aware of any. And even if it were possible, I'm not sure putting 
tables with "version - feature-set" tables into the driver proper would be 
a very good idea. It used to be like that (or almost like that with 
dependencies on the chip-type) in other drivers (e.g., shdma) and we 
dropped it in favour of platform data.

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

Re: [PATCH 1/2] V4L: sh_mobile_ceu_camera: maximum image size depends on the hardware version

[Laurent Pinchart]

Hi Guennadi,

On Wednesday 14 March 2012 16:02:20 Guennadi Liakhovetski wrote:
> Newer CEU versions, e.g., the one, used on sh7372, support image sizes
> larger than 2560x1920. Retrieve maximum sizes from platform properties.

Isn't there a way you could query the CEU version at runtime instead ?

-- 
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] [media] uvcvideo: remove unneeded access_ok() check

[Laurent Pinchart]

Hi Dan,

Thank you for the patch.

On Wednesday 21 March 2012 09:35:23 Dan Carpenter wrote:
> copy_in_user() already checks for write permission, so we don't need to
> do it here.  This was added in 1a5e4c867c "[media] uvcvideo: Implement
> compat_ioctl32 for custom ioctls".
> 
> Signed-off-by: Dan Carpenter 

Acked-by: Laurent Pinchart 

And applied to my tree.

> diff --git a/drivers/media/video/uvc/uvc_v4l2.c
> b/drivers/media/video/uvc/uvc_v4l2.c index ff2cddd..111bfff 100644
> --- a/drivers/media/video/uvc/uvc_v4l2.c
> +++ b/drivers/media/video/uvc/uvc_v4l2.c
> @@ -1105,8 +1105,6 @@ static int uvc_v4l2_put_xu_mapping(const struct
> uvc_xu_control_mapping *kp, if (get_user(p, &up->menu_info))
>   return -EFAULT;
>   umenus = compat_ptr(p);
> - if (!access_ok(VERIFY_WRITE, umenus, kp->menu_count * sizeof(*umenus)))
> - return -EFAULT;
> 
>   if (copy_in_user(umenus, kmenus, kp->menu_count * sizeof(*umenus)))
>   return -EFAULT;

-- 
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 05/16] mm/drivers: use vm_flags_t for vma flags

[Laurent Pinchart]

Hi Konstantin,

Thanks for the patch.

On Wednesday 21 March 2012 10:56:33 Konstantin Khlebnikov wrote:
> Signed-off-by: Konstantin Khlebnikov 
> Cc: linux-media@vger.kernel.org
> Cc: de...@driverdev.osuosl.org
> Cc: Laurent Pinchart 
> Cc: Mauro Carvalho Chehab 
> Cc: Greg Kroah-Hartman 
> Cc: John Stultz 
> Cc: "Arve Hjønnevåg" 
> ---
>  drivers/media/video/omap3isp/ispqueue.h |2 +-

For the OMAP3 ISP driver,

Acked-by: Laurent Pinchart 

>  drivers/staging/android/ashmem.c|2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/video/omap3isp/ispqueue.h
> b/drivers/media/video/omap3isp/ispqueue.h index 92c5a12..908dfd7 100644
> --- a/drivers/media/video/omap3isp/ispqueue.h
> +++ b/drivers/media/video/omap3isp/ispqueue.h
> @@ -90,7 +90,7 @@ struct isp_video_buffer {
>   void *vaddr;
> 
>   /* For userspace buffers. */
> - unsigned long vm_flags;
> + vm_flags_t vm_flags;
>   unsigned long offset;
>   unsigned int npages;
>   struct page **pages;
> diff --git a/drivers/staging/android/ashmem.c
> b/drivers/staging/android/ashmem.c index 9f1f27e..4511420 100644
> --- a/drivers/staging/android/ashmem.c
> +++ b/drivers/staging/android/ashmem.c
> @@ -269,7 +269,7 @@ out:
>   return ret;
>  }
> 
> -static inline unsigned long calc_vm_may_flags(unsigned long prot)
> +static inline vm_flags_t calc_vm_may_flags(unsigned long prot)
>  {
>   return _calc_vm_trans(prot, PROT_READ,  VM_MAYREAD) |
>  _calc_vm_trans(prot, PROT_WRITE, VM_MAYWRITE) |
> 

-- 
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 v5 14/35] v4l: Add DPCM compressed raw bayer pixel formats

[Sakari Ailus]

Hi Prabhakar,

Prabhakar Lad wrote:

On Tue, Mar 6, 2012 at 10:02 PM, Sakari Ailus  wrote:

...

diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10dpcm8.xml
b/Documentation/DocBook/media/v4l/pixfmt-srggb10dpcm8.xml
new file mode 100644
index 000..80937f1
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-srggb10dpcm8.xml
@@ -0,0 +1,29 @@
+
+
+
+V4L2_PIX_FMT_SRGGB10DPCM8 ('bBA8'),
+V4L2_PIX_FMT_SGBRG10DPCM8 ('bGA8'),
+V4L2_PIX_FMT_SGRBG10DPCM8 ('BD10'),
+V4L2_PIX_FMT_SBGGR10DPCM8 ('bRA8'),
+


You missed here to change as per the 4CC code documentation.


Thanks!

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

Re: [PATCH v5 14/35] v4l: Add DPCM compressed raw bayer pixel formats

[Prabhakar Lad]

Sakari,

On Tue, Mar 6, 2012 at 10:02 PM, Sakari Ailus  wrote:
>
> Add three other colour orders for 10-bit to 8-bit DPCM compressed raw
> bayer
> pixel formats.
>
> Signed-off-by: Sakari Ailus 
> ---
>  Documentation/DocBook/media/v4l/pixfmt-srggb10.xml |    2 +-
>  .../DocBook/media/v4l/pixfmt-srggb10dpcm8.xml      |   29
> 
>  Documentation/DocBook/media/v4l/pixfmt.xml         |    1 +
>  include/linux/videodev2.h                          |    3 ++
>  4 files changed, 34 insertions(+), 1 deletions(-)
>  create mode 100644
> Documentation/DocBook/media/v4l/pixfmt-srggb10dpcm8.xml
>
> diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10.xml
> b/Documentation/DocBook/media/v4l/pixfmt-srggb10.xml
> index 7b27409..c1c62a9 100644
> --- a/Documentation/DocBook/media/v4l/pixfmt-srggb10.xml
> +++ b/Documentation/DocBook/media/v4l/pixfmt-srggb10.xml
> @@ -1,4 +1,4 @@
> -    
> +    
>       
>        V4L2_PIX_FMT_SRGGB10 ('RG10'),
>         V4L2_PIX_FMT_SGRBG10 ('BA10'),
> diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10dpcm8.xml
> b/Documentation/DocBook/media/v4l/pixfmt-srggb10dpcm8.xml
> new file mode 100644
> index 000..80937f1
> --- /dev/null
> +++ b/Documentation/DocBook/media/v4l/pixfmt-srggb10dpcm8.xml
> @@ -0,0 +1,29 @@
> +    
> +      
> +       
> +        V4L2_PIX_FMT_SRGGB10DPCM8 ('bBA8'),
> +        V4L2_PIX_FMT_SGBRG10DPCM8 ('bGA8'),
> +        V4L2_PIX_FMT_SGRBG10DPCM8 ('BD10'),
> +        V4L2_PIX_FMT_SBGGR10DPCM8 ('bRA8'),
> +        

You missed here to change as per the 4CC code documentation.

Regards,
--Prabhakar Lad

> +       &manvol;
> +      
> +      
> +        id="V4L2-PIX-FMT-SRGGB10DPCM8">V4L2_PIX_FMT_SRGGB10DPCM8
> +        id="V4L2-PIX-FMT-SGBRG10DPCM8">V4L2_PIX_FMT_SGBRG10DPCM8
> +        id="V4L2-PIX-FMT-SGRBG10DPCM8">V4L2_PIX_FMT_SGRBG10DPCM8
> +        id="V4L2-PIX-FMT-SBGGR10DPCM8">V4L2_PIX_FMT_SBGGR10DPCM8
> +       10-bit Bayer formats compressed to 8 bits
> +      
> +      
> +       Description
> +
> +       The following four pixel formats are raw sRGB / Bayer
> formats
> +       with 10 bits per colour compressed to 8 bits each, using DPCM
> +       compression. DPCM, differential pulse-code modulation, is lossy.
> +       Each colour component consumes 8 bits of memory. In other respects
> +       this format is similar to  +       linkend="pixfmt-srggb10">.
> +
> +      
> +    
> diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml
> b/Documentation/DocBook/media/v4l/pixfmt.xml
> index 31eaae2..74d4fcd 100644
> --- a/Documentation/DocBook/media/v4l/pixfmt.xml
> +++ b/Documentation/DocBook/media/v4l/pixfmt.xml
> @@ -673,6 +673,7 @@ access the palette, this must be done with ioctls of
> the Linux framebuffer API.<
>     &sub-srggb8;
>     &sub-sbggr16;
>     &sub-srggb10;
> +    &sub-srggb10dpcm8;
>     &sub-srggb12;
>   
>
> diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> index f46350e..76f3153 100644
> --- a/include/linux/videodev2.h
> +++ b/include/linux/videodev2.h
> @@ -378,7 +378,10 @@ struct v4l2_pix_format {
>  #define V4L2_PIX_FMT_SGRBG12 v4l2_fourcc('B', 'A', '1', '2') /* 12
>  GRGR.. BGBG.. */
>  #define V4L2_PIX_FMT_SRGGB12 v4l2_fourcc('R', 'G', '1', '2') /* 12
>  RGRG.. GBGB.. */
>        /* 10bit raw bayer DPCM compressed to 8 bits */
> +#define V4L2_PIX_FMT_SBGGR10DPCM8 v4l2_fourcc('b', 'B', 'A', '8')
> +#define V4L2_PIX_FMT_SGBRG10DPCM8 v4l2_fourcc('b', 'G', 'A', '8')
>  #define V4L2_PIX_FMT_SGRBG10DPCM8 v4l2_fourcc('B', 'D', '1', '0')
> +#define V4L2_PIX_FMT_SRGGB10DPCM8 v4l2_fourcc('b', 'R', 'A', '8')
>        /*
>         * 10bit raw bayer, expanded to 16 bits
>         * rrgg ggbb...
> --
> 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
--
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: [Q] v4l buffer format inside isoc

[Jean-Francois Moine]

On Tue, 20 Mar 2012 21:05:13 -0300
Ezequiel García  wrote:

> I'm a little lost while writing a driver for an easycap device
> (saa7113 capture device).
> I have my isoc handler, and the isoc urb flying OK.
> I also have the videobuf2 queue setup (or at least I think so), and I 
> understand
> I need to call vb2_buffer_done() with a filled buffer.
> 
> What I DON'T understand is how should I fill such buffer?
> I mean, what *format* comes inside the isoc buffer?
> 
> Should I look at saa7113 datasheet?
> Should I base in em28xx?
> 
> I'm sorry to ask such a generic question.
> Perhaps, someone cares enough to give me a hint.

Hi Ezequiel,

The saa7113 chip is (also?) handled by the gspca spca506 subdriver
which may be a base for your device.

In the gspca test tarball (see my site), I merged the spca506 code into
the spca505 for a webcam which may also do analog video capture. The
webcam works, but the analog video capture has never been tested.
Also, the gspca_main <-> subdriver interface for vidioc_s_input and
vidioc_s_std is not very clean.

So, you might include your device in this new spca505 subdriver,
forgetting about urb, isoc, videobuf.., and just concentrating on the
device management (image format, video controls, USB exchanges..). I am
ready to cleanup and extend the gspca subdriver interface to handle any
specific need.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
--
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/3] Basic AF9035/AF9033 driver

[Oliver Schinagl]

On 20-03-12 17:27, Gianluca Gennari wrote:

Hi Michael,

Il 20/03/2012 14:04, Michael Büsch ha scritto:

Thank you for working on a af903x driver.

I tried to test the driver on a debian 3.2 kernel, after applying a small fix:
It should be CONFIG_DVB_USB_AF903X here.

this issue is fixed in version "1.02" of the driver, posted by Hans a
few days ago.


So I'm wondering how big the differences between the fc0011 and fc0012 are.
Can the 0011 be implemented in the 0012 driver, or does it require a separate 
driver?
Please give me a few hints, to I can work on implementing support for that 
tuner.

I have no idea about the real differences between the two tuner models,
but here you can find an old "leaked" af9035 driver with support for
several tuners, including fc0011 and fc0012:

https://bitbucket.org/voltagex/af9035/src
I also have a git repository, http://git.schinagl.nl/AF903x_SRC.git 
which should work with recent kernels. I haven't tested it extensively 
however, seeing what this new AF9035 driver will do for my stick :)


(look under the "api" subdir for the tuners).
The driver is not working with recent kernels, but probably you can
extract the information needed to implement a proper kernel driver for
fc0011, using the fc0012 driver written by Hans as a reference.

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

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

[PATCH 05/16] mm/drivers: use vm_flags_t for vma flags

[Konstantin Khlebnikov]

Signed-off-by: Konstantin Khlebnikov 
Cc: linux-media@vger.kernel.org
Cc: de...@driverdev.osuosl.org
Cc: Laurent Pinchart 
Cc: Mauro Carvalho Chehab 
Cc: Greg Kroah-Hartman 
Cc: John Stultz 
Cc: "Arve Hjønnevåg" 
---
 drivers/media/video/omap3isp/ispqueue.h |2 +-
 drivers/staging/android/ashmem.c|2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/video/omap3isp/ispqueue.h 
b/drivers/media/video/omap3isp/ispqueue.h
index 92c5a12..908dfd7 100644
--- a/drivers/media/video/omap3isp/ispqueue.h
+++ b/drivers/media/video/omap3isp/ispqueue.h
@@ -90,7 +90,7 @@ struct isp_video_buffer {
void *vaddr;
 
/* For userspace buffers. */
-   unsigned long vm_flags;
+   vm_flags_t vm_flags;
unsigned long offset;
unsigned int npages;
struct page **pages;
diff --git a/drivers/staging/android/ashmem.c b/drivers/staging/android/ashmem.c
index 9f1f27e..4511420 100644
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -269,7 +269,7 @@ out:
return ret;
 }
 
-static inline unsigned long calc_vm_may_flags(unsigned long prot)
+static inline vm_flags_t calc_vm_may_flags(unsigned long prot)
 {
return _calc_vm_trans(prot, PROT_READ,  VM_MAYREAD) |
   _calc_vm_trans(prot, PROT_WRITE, VM_MAYWRITE) |

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