Re: [PATCH] dma-buf: might_sleep() in dma_buf_unmap_attachment()

2012-09-28 Thread Sumit Semwal

On Friday 28 September 2012 01:09 PM, Maarten Lankhorst wrote:

Op 28-09-12 09:29, Rob Clark schreef:

From: Rob Clark 

We never really clarified if unmap could be done in atomic context.
But since mapping might require sleeping, this implies mutex in use
to synchronize mapping/unmapping, so unmap could sleep as well.  Add
a might_sleep() to clarify this.

Signed-off-by: Rob Clark 
Acked-by: Daniel Vetter 
---
  drivers/base/dma-buf.c |2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index c30f3e1..877eacb 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -298,6 +298,8 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment 
*attach,
struct sg_table *sg_table,
enum dma_data_direction direction)
  {
+   might_sleep();
+
if (WARN_ON(!attach || !attach->dmabuf || !sg_table))
return;


Looks good to me!

Reviewed-by: Maarten Lankhorst 

Thanks Rob,

Applied to for-next.

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



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


Re: [PATCH v2 3/3] mt9v022: set y_skip_top field to zero as default

2012-09-28 Thread Eric Miao
On Fri, Sep 28, 2012 at 8:21 PM, Guennadi Liakhovetski
 wrote:
> Hi Eric
>
> On Fri, 28 Sep 2012, Guennadi Liakhovetski wrote:
>
>> Hi Anatolij
>>
>> I can take this patch, but we need an ack from a PXA / ARM maintainer.
>
> Could we have your ack, please?

Yes, this looks completely good to me. Sorry for the delay.

Acked-by: Eric Miao 

>
> Thanks
> Guennadi
>
>> On Fri, 28 Sep 2012, Anatolij Gustschin wrote:
>>
>> > Set "y_skip_top" to zero and revise comment as I do not see this line
>> > corruption on two different mt9v022 setups. The first read-out line
>> > is perfectly fine. Add mt9v022 platform data configuring y_skip_top
>> > for platforms that have issues with the first read-out line. Set
>> > y_skip_top to 1 for pcm990 board.
>> >
>> > Signed-off-by: Anatolij Gustschin 
>> > ---
>> > Changes since first version:
>> >  - add platform data to mt9v022 with only one parameter to initialise
>> >y_skip_top, use 0 as default and set it to 1 on pcm990-baseboard.c
>> >  - revise commit log
>> >  - rebase on staging/for_v3.7 branch
>> >
>> >  arch/arm/mach-pxa/pcm990-baseboard.c   |6 ++
>> >  drivers/media/i2c/soc_camera/mt9v022.c |8 +---
>> >  include/media/mt9v022.h|   16 
>> >  3 files changed, 27 insertions(+), 3 deletions(-)
>> >  create mode 100644 include/media/mt9v022.h
>> >
>> > diff --git a/arch/arm/mach-pxa/pcm990-baseboard.c 
>> > b/arch/arm/mach-pxa/pcm990-baseboard.c
>> > index cb723e8..e2973f2 100644
>> > --- a/arch/arm/mach-pxa/pcm990-baseboard.c
>> > +++ b/arch/arm/mach-pxa/pcm990-baseboard.c
>> > @@ -26,6 +26,7 @@
>> >  #include 
>> >  #include 
>> >
>> > +#include 
>> >  #include 
>> >
>> >  #include 
>> > @@ -468,6 +469,10 @@ static struct i2c_board_info __initdata 
>> > pcm990_i2c_devices[] = {
>> > },
>> >  };
>> >
>> > +static struct mt9v022_platform_data mt9v022_pdata = {
>> > +   .y_skip_top = 1,
>> > +};
>> > +
>> >  static struct i2c_board_info pcm990_camera_i2c[] = {
>> > {
>> > I2C_BOARD_INFO("mt9v022", 0x48),
>> > @@ -480,6 +485,7 @@ static struct soc_camera_link iclink[] = {
>> > {
>> > .bus_id = 0, /* Must match with the camera ID 
>> > */
>> > .board_info = &pcm990_camera_i2c[0],
>> > +   .priv   = &mt9v022_pdata,
>> > .i2c_adapter_id = 0,
>> > .query_bus_param= pcm990_camera_query_bus_param,
>> > .set_bus_param  = pcm990_camera_set_bus_param,
>> > diff --git a/drivers/media/i2c/soc_camera/mt9v022.c 
>> > b/drivers/media/i2c/soc_camera/mt9v022.c
>> > index e0f4cb4..8feaddc 100644
>> > --- a/drivers/media/i2c/soc_camera/mt9v022.c
>> > +++ b/drivers/media/i2c/soc_camera/mt9v022.c
>> > @@ -15,6 +15,7 @@
>> >  #include 
>> >  #include 
>> >
>> > +#include 
>> >  #include 
>> >  #include 
>> >  #include 
>> > @@ -849,6 +850,7 @@ static int mt9v022_probe(struct i2c_client *client,
>> > struct mt9v022 *mt9v022;
>> > struct soc_camera_link *icl = soc_camera_i2c_to_link(client);
>> > struct i2c_adapter *adapter = to_i2c_adapter(client->dev.parent);
>> > +   struct mt9v022_platform_data *pdata = icl->priv;
>> > int ret;
>> >
>> > if (!icl) {
>> > @@ -912,10 +914,10 @@ static int mt9v022_probe(struct i2c_client *client,
>> > mt9v022->chip_control = MT9V022_CHIP_CONTROL_DEFAULT;
>> >
>> > /*
>> > -* MT9V022 _really_ corrupts the first read out line.
>> > -* TODO: verify on i.MX31
>> > +* On some platforms the first read out line is corrupted.
>> > +* Workaround it by skipping if indicated by platform data.
>> >  */
>> > -   mt9v022->y_skip_top = 1;
>> > +   mt9v022->y_skip_top = pdata ? pdata->y_skip_top : 0;
>> > mt9v022->rect.left  = MT9V022_COLUMN_SKIP;
>> > mt9v022->rect.top   = MT9V022_ROW_SKIP;
>> > mt9v022->rect.width = MT9V022_MAX_WIDTH;
>> > diff --git a/include/media/mt9v022.h b/include/media/mt9v022.h
>> > new file mode 100644
>> > index 000..4056180
>> > --- /dev/null
>> > +++ b/include/media/mt9v022.h
>> > @@ -0,0 +1,16 @@
>> > +/*
>> > + * mt9v022 sensor
>> > + *
>> > + * This program is free software; you can redistribute it and/or modify
>> > + * it under the terms of the GNU General Public License version 2 as
>> > + * published by the Free Software Foundation.
>> > + */
>> > +
>> > +#ifndef __MT9V022_H__
>> > +#define __MT9V022_H__
>> > +
>> > +struct mt9v022_platform_data {
>> > +   unsigned short y_skip_top;  /* Lines to skip at the top */
>> > +};
>> > +
>> > +#endif
>> > --
>> > 1.7.1
>> >
>>
>> ---
>> Guennadi Liakhovetski, Ph.D.
>> Freelance Open-Source Software Developer
>> http://www.open-technology.de/
>>
>
> ---
> 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

Re: [PATCH 1/5] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER

2012-09-28 Thread Thomas Hellstrom

On 09/28/2012 09:42 PM, Thomas Hellstrom wrote:

On 09/28/2012 04:14 PM, Maarten Lankhorst wrote:

Hey,

Op 28-09-12 14:41, Maarten Lankhorst schreef:

Documentation says that code requiring dma-buf should add it to
select, so inline fallbacks are not going to be used. A link error
will make it obvious what went wrong, instead of silently doing
nothing at runtime.




The whole patch series is in my tree, I use stg so things might
move around, do not use for merging currently:

http://cgit.freedesktop.org/~mlankhorst/linux/log/?h=v10-wip

It contains everything in here plus the patches for ttm to make
it work, I use a old snapshot of drm-next + merge of nouveau as
base. Description of what the parts do:

Series to fix small api issues when moving over:

drm/ttm: Remove cpu_writers related code
drm/ttm: Add ttm_bo_is_reserved function
drm/radeon: Use ttm_bo_is_reserved
drm/vmwgfx: use ttm_bo_is_reserved

drm/vmwgfx: remove use of fence_obj_args
drm/ttm: remove sync_obj_arg
drm/ttm: remove sync_obj_arg from ttm_bo_move_accel_cleanup
drm/ttm: remove sync_arg entirely

drm/nouveau: unpin buffers before releasing to prevent lockdep warnings
drm/nouveau: add reservation to nouveau_bo_vma_del
drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep

Hey great, now we only have one user left for fence waiting before 
reserving,

lets fix that and remove fence lock:
ttm_bo_cleanup_refs_or_queue and ttm_bo_cleanup_refs have to reserve 
before
waiting, lets do it in the squash commit so we don't have to throw 
lock order

around everywhere:

drm/ttm: remove fence_lock

-- Up to this point should be mergeable now

Then we start working on lru_lock removal slightly, this means the lru
list no longer is empty but can contain only reserved buffers:

drm/ttm: do not check if list is empty in ttm_bo_force_list_clean
drm/ttm: move reservations for ttm_bo_cleanup_refs

-- Still mergeable up to this point, just fixes

Patch series from this email:
dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER
fence: dma-buf cross-device synchronization (v9)
seqno-fence: Hardware dma-buf implementation of fencing (v3)
reservation: cross-device reservation support
reservation: Add lockdep annotation and selftests

Now hook it up to drm/ttm in a few steps:
usage around reservations:
drm/ttm: make ttm reservation calls behave like reservation calls
drm/ttm: use dma_reservation api
dma-buf: use reservations
drm/ttm: allow drivers to pass custom dma_reservation_objects for a bo

then kill off the lru lock around reservation:
drm/ttm: remove lru_lock around ttm_bo_reserve
drm/ttm: simplify ttm_eu_*

The lru_lock removal patch removes the lock around lru_lock around the
reservation, this will break the assumption that items on the lru list
and swap list can always be reserved, and this gets patched up too.
Is there any part in ttm you disagree with? I believe that this
is all mergeable, the lru_lock removal patch could be moved to before
the reservation parts, this might make merging easier, but I don't
think there is any ttm part of the series that are wrong on a conceptual
level.

~Maarten


From another email

As previously discussed, I'm unfortunately not prepared to accept 
removal of the reserve-lru atomicity

  into the TTM code at this point.
The current code is based on this assumption and removing it will 
end up with
efficiencies, breaking the delayed delete code and probably a 
locking nightmare when trying to write

new TTM code.
The lru lock removal patch fixed the delayed delete code, it really 
is not different from the current
situation. In fact it is more clear without the guarantee what 
various parts are trying to protect.


Nothing prevents you from holding the lru_lock while trylocking,

[1]
While this would not cause any deadlocks, Any decent lockdep code 
would establish lru->reserve as the locking
order once a lru- reserve trylock succeeds, but the locking order is 
really reserve->lru for obvious reasons, which
means we will get a lot of lockdep errors? Yes, there are a two 
reversals like these already in the TTM code, and I'm

not very proud of them.

leaving that guarantee intact for that part. Can you really just review
the patch and tell me where it breaks and/or makes the code unreadable?

OK. Now I'm looking at
http://cgit.freedesktop.org/~mlankhorst/linux/tree/drivers/gpu/drm/ttm/ttm_bo.c?h=v10-wip&id=1436e2e64697c744d6e186618448e1e6354846bb 



And let's start with a function that's seen some change, 
ttm_mem_evict_first:


*) Line 715: You're traversing a list using list_for_each() calling a 
function that may remove the list entry
*) Line 722: You're unlocking the lock protecting the list in the 
middle of list traversal

*) Line 507: WARN_ON_ONCE in a code path quite likely to get called?
*) Line 512: sleep while atomic
*) Line 729: Forgot to unreserve
*) Line 730: Forgot to lock lru
*) Line 735: Now you're restarting with the first item on the LRU 
list. Why the loop at line 715?

*) Line 740

Re: [PATCH 1/5] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER

2012-09-28 Thread Thomas Hellstrom

On 09/28/2012 04:14 PM, Maarten Lankhorst wrote:

Hey,

Op 28-09-12 14:41, Maarten Lankhorst schreef:

Documentation says that code requiring dma-buf should add it to
select, so inline fallbacks are not going to be used. A link error
will make it obvious what went wrong, instead of silently doing
nothing at runtime.

   



The whole patch series is in my tree, I use stg so things might
move around, do not use for merging currently:

http://cgit.freedesktop.org/~mlankhorst/linux/log/?h=v10-wip

It contains everything in here plus the patches for ttm to make
it work, I use a old snapshot of drm-next + merge of nouveau as
base. Description of what the parts do:

Series to fix small api issues when moving over:

drm/ttm: Remove cpu_writers related code
drm/ttm: Add ttm_bo_is_reserved function
drm/radeon: Use ttm_bo_is_reserved
drm/vmwgfx: use ttm_bo_is_reserved

drm/vmwgfx: remove use of fence_obj_args
drm/ttm: remove sync_obj_arg
drm/ttm: remove sync_obj_arg from ttm_bo_move_accel_cleanup
drm/ttm: remove sync_arg entirely

drm/nouveau: unpin buffers before releasing to prevent lockdep warnings
drm/nouveau: add reservation to nouveau_bo_vma_del
drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep

Hey great, now we only have one user left for fence waiting before reserving,
lets fix that and remove fence lock:
ttm_bo_cleanup_refs_or_queue and ttm_bo_cleanup_refs have to reserve before
waiting, lets do it in the squash commit so we don't have to throw lock order
around everywhere:

drm/ttm: remove fence_lock

-- Up to this point should be mergeable now

Then we start working on lru_lock removal slightly, this means the lru
list no longer is empty but can contain only reserved buffers:

drm/ttm: do not check if list is empty in ttm_bo_force_list_clean
drm/ttm: move reservations for ttm_bo_cleanup_refs

-- Still mergeable up to this point, just fixes

Patch series from this email:
dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER
fence: dma-buf cross-device synchronization (v9)
seqno-fence: Hardware dma-buf implementation of fencing (v3)
reservation: cross-device reservation support
reservation: Add lockdep annotation and selftests

Now hook it up to drm/ttm in a few steps:
usage around reservations:
drm/ttm: make ttm reservation calls behave like reservation calls
drm/ttm: use dma_reservation api
dma-buf: use reservations
drm/ttm: allow drivers to pass custom dma_reservation_objects for a bo

then kill off the lru lock around reservation:
drm/ttm: remove lru_lock around ttm_bo_reserve
drm/ttm: simplify ttm_eu_*

The lru_lock removal patch removes the lock around lru_lock around the
reservation, this will break the assumption that items on the lru list
and swap list can always be reserved, and this gets patched up too.
Is there any part in ttm you disagree with? I believe that this
is all mergeable, the lru_lock removal patch could be moved to before
the reservation parts, this might make merging easier, but I don't
think there is any ttm part of the series that are wrong on a conceptual
level.

~Maarten


From another email


As previously discussed, I'm unfortunately not prepared to accept removal of 
the reserve-lru atomicity
  into the TTM code at this point.
The current code is based on this assumption and removing it will end up with
efficiencies, breaking the delayed delete code and probably a locking nightmare 
when trying to write
new TTM code.

The lru lock removal patch fixed the delayed delete code, it really is not 
different from the current
situation. In fact it is more clear without the guarantee what various parts 
are trying to protect.

Nothing prevents you from holding the lru_lock while trylocking,

[1]
While this would not cause any deadlocks, Any decent lockdep code would 
establish lru->reserve as the locking
order once a lru- reserve trylock succeeds, but the locking order is 
really reserve->lru for obvious reasons, which
means we will get a lot of lockdep errors? Yes, there are a two 
reversals like these already in the TTM code, and I'm

not very proud of them.

leaving that guarantee intact for that part. Can you really just review
the patch and tell me where it breaks and/or makes the code unreadable?

OK. Now I'm looking at
http://cgit.freedesktop.org/~mlankhorst/linux/tree/drivers/gpu/drm/ttm/ttm_bo.c?h=v10-wip&id=1436e2e64697c744d6e186618448e1e6354846bb

And let's start with a function that's seen some change, 
ttm_mem_evict_first:


*) Line 715: You're traversing a list using list_for_each() calling a 
function that may remove the list entry
*) Line 722: You're unlocking the lock protecting the list in the middle 
of list traversal

*) Line 507: WARN_ON_ONCE in a code path quite likely to get called?
*) Line 512: sleep while atomic
*) Line 729: Forgot to unreserve
*) Line 730: Forgot to lock lru
*) Line 735: Now you're restarting with the first item on the LRU list. 
Why the loop at line 715?

*) Line 740: Deadlocking reserve
*) Line 757: Calling TTM Bo evict

Re: [PATCH] tda18271-common: hold the I2C adapter during write transfers

2012-09-28 Thread Michael Krufky
On Fri, Sep 28, 2012 at 2:31 PM, Antti Palosaari  wrote:
> Hello,
> Did not fix the issue. Problem remains same. With the sleep + that patch it
> works still.
>
> On 09/28/2012 06:04 PM, Mauro Carvalho Chehab wrote:
>>
>> The tda18271 datasheet says:
>>
>> "The image rejection calibration and RF tracking filter
>>  calibration must be launched exactly as described in the
>>  flowchart, otherwise bad calibration or even blocking of the
>>  TDA18211HD can result making it impossible to communicate
>>  via the I2C-bus."
>>
>> (yeah, tda18271 refers there to tda18211 - likely a typo at their
>>   datasheets)
>
>
> tda18211 is just same than tda18271 but without a analog.
>
>> That likely explains why sometimes tda18271 stops answering. That
>> is now happening more often on designs with drx-k chips, as the
>> firmware is now loaded asyncrousnly there.
>>
>> While the above text doesn't explicitly tell that the I2C bus
>> couldn't be used by other devices during such initialization,
>> that seems to be a requirement there.
>>
>> So, let's explicitly use the I2C lock there, avoiding I2C bus
>> share during those critical moments.
>>
>> Compile-tested only. Please test.
>>
>> Signed-off-by: Mauro Carvalho Chehab 
>> ---
>>   drivers/media/tuners/tda18271-common.c | 104
>> ++---
>>   1 file changed, 71 insertions(+), 33 deletions(-)
>>
>> diff --git a/drivers/media/tuners/tda18271-common.c
>> b/drivers/media/tuners/tda18271-common.c
>> index 221171e..18c77af 100644
>> --- a/drivers/media/tuners/tda18271-common.c
>> +++ b/drivers/media/tuners/tda18271-common.c
>> @@ -187,7 +187,8 @@ int tda18271_read_extended(struct dvb_frontend *fe)
>> return (ret == 2 ? 0 : ret);
>>   }
>>
>> -int tda18271_write_regs(struct dvb_frontend *fe, int idx, int len)
>> +static int __tda18271_write_regs(struct dvb_frontend *fe, int idx, int
>> len,
>> +   bool lock_i2c)
>>   {
>> struct tda18271_priv *priv = fe->tuner_priv;
>> unsigned char *regs = priv->tda18271_regs;
>> @@ -198,7 +199,6 @@ int tda18271_write_regs(struct dvb_frontend *fe, int
>> idx, int len)
>>
>> BUG_ON((len == 0) || (idx + len > sizeof(buf)));
>>
>> -
>> switch (priv->small_i2c) {
>> case TDA18271_03_BYTE_CHUNK_INIT:
>> max = 3;
>> @@ -214,7 +214,19 @@ int tda18271_write_regs(struct dvb_frontend *fe, int
>> idx, int len)
>> max = 39;
>> }
>>
>> -   tda18271_i2c_gate_ctrl(fe, 1);
>> +
>> +   /*
>> +* If lock_i2c is true, it will take the I2C bus for tda18271
>> private
>> +* usage during the entire write ops, as otherwise, bad things
>> could
>> +* happen.
>> +* During device init, several write operations will happen. So,
>> +* tda18271_init_regs controls the I2C lock directly,
>> +* disabling lock_i2c here.
>> +*/
>> +   if (lock_i2c) {
>> +   tda18271_i2c_gate_ctrl(fe, 1);
>> +   i2c_lock_adapter(priv->i2c_props.adap);
>> +   }
>> while (len) {
>> if (max > len)
>> max = len;
>> @@ -226,14 +238,17 @@ int tda18271_write_regs(struct dvb_frontend *fe, int
>> idx, int len)
>> msg.len = max + 1;
>>
>> /* write registers */
>> -   ret = i2c_transfer(priv->i2c_props.adap, &msg, 1);
>> +   ret = __i2c_transfer(priv->i2c_props.adap, &msg, 1);
>> if (ret != 1)
>> break;
>>
>> idx += max;
>> len -= max;
>> }
>> -   tda18271_i2c_gate_ctrl(fe, 0);
>> +   if (lock_i2c) {
>> +   i2c_unlock_adapter(priv->i2c_props.adap);
>> +   tda18271_i2c_gate_ctrl(fe, 0);
>> +   }
>>
>> if (ret != 1)
>> tda_err("ERROR: idx = 0x%x, len = %d, "
>> @@ -242,10 +257,16 @@ int tda18271_write_regs(struct dvb_frontend *fe, int
>> idx, int len)
>> return (ret == 1 ? 0 : ret);
>>   }
>>
>> +int tda18271_write_regs(struct dvb_frontend *fe, int idx, int len)
>> +{
>> +   return __tda18271_write_regs(fe, idx, len, true);
>> +}
>> +
>>
>> /*-*/
>>
>> -int tda18271_charge_pump_source(struct dvb_frontend *fe,
>> -   enum tda18271_pll pll, int force)
>> +static int __tda18271_charge_pump_source(struct dvb_frontend *fe,
>> +enum tda18271_pll pll, int force,
>> +bool lock_i2c)
>>   {
>> struct tda18271_priv *priv = fe->tuner_priv;
>> unsigned char *regs = priv->tda18271_regs;
>> @@ -255,9 +276,16 @@ int tda18271_charge_pump_source(struct dvb_frontend
>> *fe,
>> regs[r_cp] &= ~0x20;
>> regs[r_cp] |= ((force & 1) << 5);
>>
>> -   return tda18271_write_regs(fe, r_cp, 1);
>> +   return _

Re: [PATCH] usb id addition for Terratec Cinergy T Stick Dual rev. 2

2012-09-28 Thread Malcolm Priestley
On Fri, 2012-09-28 at 20:55 +0300, Antti Palosaari wrote:
> On 09/28/2012 07:34 PM, Damien Bally wrote:
> >   > I will NACK that initially because that USB ID already used by AF9015
> >> driver. You have to explain / study what happens when AF9015 driver
> >> claims that device same time.
> >>
> >
> > Hi Antti
> >
> > With the Cinergy stick alone, dvb_usb_af9015 is predictably loaded, but
> > doesn't prevent dvb_usb_it913x from working nicely.
> >
> > If an afatech 9015 stick is connected, such as an AverTV Volar Black HD
> > (A850), it will be recognized and doesn't affect the other device.
> >
> > *But* it runs into trouble if the two devices were connected at bootup,
> > or if the Cinergy stick is inserted after the other one :
> 
> I am not sure what you do here but let it be clear.
> There is same ID used by af9015 and it913x. Both drivers are loaded when 
> that ID appears. What I understand *both* drivers, af9015 and it913x 
> should detect if device is correct or not. If device is af9015 then 
> it913x should reject it with -ENODEV most likely without a I/O. If 
> device is it913x then af9015 should reject the device similarly. And you 
> must find out how to do that. It is not acceptable both drivers starts 
> doing I/O for same device same time.
> 
Hi All

Which module is loaded first depends on the order in 

/lib/modules/$(uname -r)/modules.usbmap

Its is likely that af9015 will be first, so the it913x will need to be
loaded first by added it to /etc/modules.

I recall a similar problem exists with the DiB3000M-B driver with its
faulty IDs.

A solution may be for Cinergy to have its own module with extern access
to both dvb_usb_device_properties structures and dvb_usbv2_probe them
twice.


Regards


Malcolm








> regards
> Antti
> 
> > ---
> > [1.264018] usb 2-1: new high speed USB device using ehci_hcd and
> > address 2
> > [1.382487] usb 2-1: New USB device found, idVendor=0ccd, idProduct=0099
> > [1.382490] usb 2-1: New USB device strings: Mfr=1, Product=2,
> > SerialNumber=0
> > [1.382492] usb 2-1: Product: DVB-T TV Stick
> > [1.382494] usb 2-1: Manufacturer: ITE Technologies, Inc.
> > [1.385073] input: ITE Technologies, Inc. DVB-T TV Stick as
> > /devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.1/input/input1
> > [1.385147] generic-usb 0003:0CCD:0099.0001: input,hidraw0: USB HID
> > v1.01 Keyboard [ITE Technologies, Inc. DVB-T TV Stick] on
> > usb-:00:1d.7-1 input1
> > [5.045527] usbcore: registered new interface driver dvb_usb_it913x
> > [5.147276] it913x: Chip Version=01 Chip Type=9135
> > [5.147524] it913x: Firmware Version 33684956
> > [5.148649] it913x: Remote HID mode NOT SUPPORTED
> > [5.149024] it913x: Dual mode=3 Tuner Type=0
> > [5.149028] usb 2-1: dvb_usbv2: found a 'ITE 9135(9006) Generic' in
> > warm state
> > [5.149077] usb 2-1: dvb_usbv2: will pass the complete MPEG2
> > transport stream to the software demuxer
> > [5.149307] DVB: registering new adapter (ITE 9135(9006) Generic)
> > [5.174907] usb 1-4: dvb_usbv2: downloading firmware from file
> > 'dvb-usb-af9015.fw'
> > [5.241934] usb 1-4: dvb_usbv2: found a 'AverMedia AVerTV Volar Black
> > HD (A850)' in warm state
> > [5.614827] usb 1-4: dvb_usbv2: will pass the complete MPEG2
> > transport stream to the software demuxer
> > [5.614866] DVB: registering new adapter (AverMedia AVerTV Volar
> > Black HD (A850))
> > [5.710026] af9013: firmware version 4.95.0.0
> > [5.712151] DVB: registering adapter 1 frontend 0 (Afatech AF9013)...
> > [5.813139] MXL5005S: Attached at address 0xc6
> > [5.818896] usb 1-4: dvb_usbv2: 'AverMedia AVerTV Volar Black HD
> > (A850)' successfully initialized and connected
> > [7.266161] usb 2-1: dvb_usbv2: 2nd usb_bulk_msg() failed=-110
> > [7.266247] it913x-fe: ADF table value:00
> > [9.267200] usb 2-1: dvb_usbv2: 2nd usb_bulk_msg() failed=-110
> > [   11.267153] usb 2-1: dvb_usbv2: 2nd usb_bulk_msg() failed=-110
> > [   13.267250] usb 2-1: dvb_usbv2: 2nd usb_bulk_msg() failed=-110
> > [   15.267089] usb 2-1: dvb_usbv2: 2nd usb_bulk_msg() failed=-110
> > [   17.267162] usb 2-1: dvb_usbv2: 2nd usb_bulk_msg() failed=-110
> > [   19.267139] usb 2-1: dvb_usbv2: 2nd usb_bulk_msg() failed=-110
> > [   19.267218] it913x-fe: Crystal Frequency :1200 Adc Frequency
> > :2025 ADC X2: 01
> > [   19.267296] usb 2-1: dvb_usbv2: 'ITE 9135(9006) Generic' error while
> > loading driver (-19)
> > [   19.267472] usb 2-1: dvb_usbv2: 'ITE 9135(9006) Generic' successfully
> > deinitialized and disconnected
> > ---
> >
> > I'm unfortunately not able to rewrite the driver, but I'm willing to
> > provide any information about the device to help its correct
> > identification. Here is what lsusb yields :
> > 

Re: [PATCH] usb id addition for Terratec Cinergy T Stick Dual rev. 2

2012-09-28 Thread Damien Bally



Le 28/09/2012 19:55, Antti Palosaari a écrit :


I am not sure what you do here but let it be clear.
There is same ID used by af9015 and it913x. Both drivers are loaded when
that ID appears. What I understand *both* drivers, af9015 and it913x
should detect if device is correct or not. If device is af9015 then
it913x should reject it with -ENODEV most likely without a I/O. If
device is it913x then af9015 should reject the device similarly. And you
must find out how to do that. It is not acceptable both drivers starts
doing I/O for same device same time.



I'd gladly implement this, but I'm not a developper, for the moment ;-)



I'm unfortunately not able to rewrite the driver, but I'm willing to
provide any information about the device to help its correct
identification.

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

2012-09-28 Thread 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:Fri Sep 28 19:00:22 CEST 2012
git hash:8928b6d1568eb9104cc9e2e6627d7086437b2fb3
gcc version:  i686-linux-gcc (GCC) 4.7.1
host hardware:x86_64
host os:  3.4.07-marune

linux-git-arm-eabi-davinci: ERRORS
linux-git-arm-eabi-exynos: WARNINGS
linux-git-arm-eabi-omap: ERRORS
linux-git-i686: WARNINGS
linux-git-m32r: WARNINGS
linux-git-mips: WARNINGS
linux-git-powerpc64: WARNINGS
linux-git-sh: WARNINGS
linux-git-x86_64: 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: ERRORS
linux-2.6.35.3-x86_64: ERRORS
linux-2.6.36-x86_64: ERRORS
linux-2.6.37-x86_64: ERRORS
linux-2.6.38.2-x86_64: ERRORS
linux-2.6.39.1-x86_64: ERRORS
linux-3.0-x86_64: ERRORS
linux-3.1-x86_64: ERRORS
linux-3.2.1-x86_64: ERRORS
linux-3.3-x86_64: ERRORS
linux-3.4-x86_64: WARNINGS
linux-3.5-x86_64: WARNINGS
linux-3.6-rc2-x86_64: WARNINGS
linux-2.6.31.12-i686: ERRORS
linux-2.6.32.6-i686: ERRORS
linux-2.6.33-i686: ERRORS
linux-2.6.34-i686: ERRORS
linux-2.6.35.3-i686: ERRORS
linux-2.6.36-i686: ERRORS
linux-2.6.37-i686: ERRORS
linux-2.6.38.2-i686: ERRORS
linux-2.6.39.1-i686: ERRORS
linux-3.0-i686: ERRORS
linux-3.1-i686: ERRORS
linux-3.2.1-i686: ERRORS
linux-3.3-i686: ERRORS
linux-3.4-i686: WARNINGS
linux-3.5-i686: WARNINGS
linux-3.6-rc2-i686: WARNINGS
apps: WARNINGS
spec-git: OK
sparse: ERRORS

Detailed results are available here:

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

Full logs are available here:

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

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

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


Re: [PATCH 2/4] [media] marvell-ccic: core: add soc camera support on marvell-ccic mcam-core

2012-09-28 Thread Sylwester Nawrocki
Hi,

On 09/28/2012 08:37 PM, Albert Wang wrote:
>>> +   ret = v4l2_subdev_call(sd, core, g_chip_ident,&id);
> 
>> Yuck. Don't abuse this. g_chip_ident is for debugging purposes only.
> 
> Yes, can remove it.
> 
>>> +   if (ret<  0) {
>>> +   cam_err(mcam, "%s %d\n", __func__, __LINE__);
>>> +   return ret;
>>> +   }
>>> +
>>> +   strcpy(cap->card, mcam->card_name);
>>> +   strncpy(cap->driver, (const char *)&(id.ident), 4);
> 
>> No, the name of the driver is the name of this module: marvell_ccic.
>> It's *not* the name of the sensor driver.
> 
> Yes, maybe you are right, we misunderstood this usage.
> 
> But I'm confused with how can we put the sensor module name to upper level?
> I mean upper level user want to know which sensor module is connecting to the 
> controller.
> Currently, our user get the sensor module name by call this ioctl 
> VIDIOC_QUERYCAP.
> 
> Anyway, maybe we need change the usage model.

Is there anything preventing you from using VIDIOC_ENUM_INPUT/VIDIOC_G_INPUT
ioctls for that ?

--

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


RE: [PATCH 2/4] [media] marvell-ccic: core: add soc camera support on marvell-ccic mcam-core

2012-09-28 Thread Albert Wang
Hi, Hans

Thank you for reviewing the patches!

>>On Fri September 28 2012 15:47:20 Albert Wang wrote:
>> 
>> This patch adds the support of Soc Camera on marvell-ccic mcam-core.
>> The Soc Camera mode does not compatible with current mode.
>> Only one mode can be used at one time.
>> 
>> To use Soc Camera, CONFIG_VIDEO_MMP_SOC_CAMERA should be defined.
>> What's more, the platform driver should support Soc camera at the same time.
>> 
>> Also add MIPI interface and dual CCICs support in Soc Camera mode.
>> 
>> Signed-off-by: Albert Wang 
>> Signed-off-by: Libin Yang 
>> ---
>>  drivers/media/platform/marvell-ccic/mcam-core.c | 1034 
>> ++  
>> drivers/media/platform/marvell-ccic/mcam-core.h |  126 +++-
>>  2 files changed, 997 insertions(+), 163 deletions(-)
>> 
>> diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c 
>> b/drivers/media/platform/marvell-ccic/mcam-core.c
>> index ce2b7b4..4adb1ca 100755
>> --- a/drivers/media/platform/marvell-ccic/mcam-core.c
>> +++ b/drivers/media/platform/marvell-ccic/mcam-core.c

...

>> +static int mcam_camera_querycap(struct soc_camera_host *ici,
>> +struct v4l2_capability *cap)
>> +{
>> +struct v4l2_dbg_chip_ident id;
>> +struct mcam_camera *mcam = ici->priv;
>> +struct soc_camera_device *icd = mcam->icd;
>> +struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
>> +int ret = 0;
>> +
>> +cap->version = KERNEL_VERSION(0, 0, 5);

>Don't fill in version. It's set to the kernel version automatically.

OK, will remove it.

>> +cap->capabilities = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING;

>Please also set cap->device_caps. See the spec.

OK, will update.

>> +ret = v4l2_subdev_call(sd, core, g_chip_ident, &id);

>Yuck. Don't abuse this. g_chip_ident is for debugging purposes only.

Yes, can remove it.

>> +if (ret < 0) {
>> +cam_err(mcam, "%s %d\n", __func__, __LINE__);
>> +return ret;
>> +}
>> +
>> +strcpy(cap->card, mcam->card_name);
>> +strncpy(cap->driver, (const char *)&(id.ident), 4);

>No, the name of the driver is the name of this module: marvell_ccic.
>It's *not* the name of the sensor driver.

Yes, maybe you are right, we misunderstood this usage.

But I'm confused with how can we put the sensor module name to upper level?
I mean upper level user want to know which sensor module is connecting to the 
controller.
Currently, our user get the sensor module name by call this ioctl 
VIDIOC_QUERYCAP.

Anyway, maybe we need change the usage model.

>> +
>> +return 0;
>> +}

>Regards
>
>   Hans

Thanks
Albert Wang
--
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] tda18271-common: hold the I2C adapter during write transfers

2012-09-28 Thread Antti Palosaari

Hello,
Did not fix the issue. Problem remains same. With the sleep + that patch 
it works still.


On 09/28/2012 06:04 PM, Mauro Carvalho Chehab wrote:

The tda18271 datasheet says:

"The image rejection calibration and RF tracking filter
 calibration must be launched exactly as described in the
 flowchart, otherwise bad calibration or even blocking of the
 TDA18211HD can result making it impossible to communicate
 via the I2C-bus."

(yeah, tda18271 refers there to tda18211 - likely a typo at their
  datasheets)


tda18211 is just same than tda18271 but without a analog.


That likely explains why sometimes tda18271 stops answering. That
is now happening more often on designs with drx-k chips, as the
firmware is now loaded asyncrousnly there.

While the above text doesn't explicitly tell that the I2C bus
couldn't be used by other devices during such initialization,
that seems to be a requirement there.

So, let's explicitly use the I2C lock there, avoiding I2C bus
share during those critical moments.

Compile-tested only. Please test.

Signed-off-by: Mauro Carvalho Chehab 
---
  drivers/media/tuners/tda18271-common.c | 104 ++---
  1 file changed, 71 insertions(+), 33 deletions(-)

diff --git a/drivers/media/tuners/tda18271-common.c 
b/drivers/media/tuners/tda18271-common.c
index 221171e..18c77af 100644
--- a/drivers/media/tuners/tda18271-common.c
+++ b/drivers/media/tuners/tda18271-common.c
@@ -187,7 +187,8 @@ int tda18271_read_extended(struct dvb_frontend *fe)
return (ret == 2 ? 0 : ret);
  }

-int tda18271_write_regs(struct dvb_frontend *fe, int idx, int len)
+static int __tda18271_write_regs(struct dvb_frontend *fe, int idx, int len,
+   bool lock_i2c)
  {
struct tda18271_priv *priv = fe->tuner_priv;
unsigned char *regs = priv->tda18271_regs;
@@ -198,7 +199,6 @@ int tda18271_write_regs(struct dvb_frontend *fe, int idx, 
int len)

BUG_ON((len == 0) || (idx + len > sizeof(buf)));

-
switch (priv->small_i2c) {
case TDA18271_03_BYTE_CHUNK_INIT:
max = 3;
@@ -214,7 +214,19 @@ int tda18271_write_regs(struct dvb_frontend *fe, int idx, 
int len)
max = 39;
}

-   tda18271_i2c_gate_ctrl(fe, 1);
+
+   /*
+* If lock_i2c is true, it will take the I2C bus for tda18271 private
+* usage during the entire write ops, as otherwise, bad things could
+* happen.
+* During device init, several write operations will happen. So,
+* tda18271_init_regs controls the I2C lock directly,
+* disabling lock_i2c here.
+*/
+   if (lock_i2c) {
+   tda18271_i2c_gate_ctrl(fe, 1);
+   i2c_lock_adapter(priv->i2c_props.adap);
+   }
while (len) {
if (max > len)
max = len;
@@ -226,14 +238,17 @@ int tda18271_write_regs(struct dvb_frontend *fe, int idx, 
int len)
msg.len = max + 1;

/* write registers */
-   ret = i2c_transfer(priv->i2c_props.adap, &msg, 1);
+   ret = __i2c_transfer(priv->i2c_props.adap, &msg, 1);
if (ret != 1)
break;

idx += max;
len -= max;
}
-   tda18271_i2c_gate_ctrl(fe, 0);
+   if (lock_i2c) {
+   i2c_unlock_adapter(priv->i2c_props.adap);
+   tda18271_i2c_gate_ctrl(fe, 0);
+   }

if (ret != 1)
tda_err("ERROR: idx = 0x%x, len = %d, "
@@ -242,10 +257,16 @@ int tda18271_write_regs(struct dvb_frontend *fe, int idx, 
int len)
return (ret == 1 ? 0 : ret);
  }

+int tda18271_write_regs(struct dvb_frontend *fe, int idx, int len)
+{
+   return __tda18271_write_regs(fe, idx, len, true);
+}
+
  /*-*/

-int tda18271_charge_pump_source(struct dvb_frontend *fe,
-   enum tda18271_pll pll, int force)
+static int __tda18271_charge_pump_source(struct dvb_frontend *fe,
+enum tda18271_pll pll, int force,
+bool lock_i2c)
  {
struct tda18271_priv *priv = fe->tuner_priv;
unsigned char *regs = priv->tda18271_regs;
@@ -255,9 +276,16 @@ int tda18271_charge_pump_source(struct dvb_frontend *fe,
regs[r_cp] &= ~0x20;
regs[r_cp] |= ((force & 1) << 5);

-   return tda18271_write_regs(fe, r_cp, 1);
+   return __tda18271_write_regs(fe, r_cp, 1, lock_i2c);
+}
+
+int tda18271_charge_pump_source(struct dvb_frontend *fe,
+   enum tda18271_pll pll, int force)
+{
+   return __tda18271_charge_pump_source(fe, pll, force, true);
  }

+
  int tda18271_init_regs(struct dvb_frontend *fe)
  {
struct tda18271_priv *priv = fe->tuner_priv;
@@ -267,6 +295,13 @@ int tda18271_init_regs(struct dvb_frontend *fe

Re: [PATCH] usb id addition for Terratec Cinergy T Stick Dual rev. 2

2012-09-28 Thread Antti Palosaari

On 09/28/2012 07:34 PM, Damien Bally wrote:

  > I will NACK that initially because that USB ID already used by AF9015

driver. You have to explain / study what happens when AF9015 driver
claims that device same time.



Hi Antti

With the Cinergy stick alone, dvb_usb_af9015 is predictably loaded, but
doesn't prevent dvb_usb_it913x from working nicely.

If an afatech 9015 stick is connected, such as an AverTV Volar Black HD
(A850), it will be recognized and doesn't affect the other device.

*But* it runs into trouble if the two devices were connected at bootup,
or if the Cinergy stick is inserted after the other one :


I am not sure what you do here but let it be clear.
There is same ID used by af9015 and it913x. Both drivers are loaded when 
that ID appears. What I understand *both* drivers, af9015 and it913x 
should detect if device is correct or not. If device is af9015 then 
it913x should reject it with -ENODEV most likely without a I/O. If 
device is it913x then af9015 should reject the device similarly. And you 
must find out how to do that. It is not acceptable both drivers starts 
doing I/O for same device same time.


regards
Antti


---
[1.264018] usb 2-1: new high speed USB device using ehci_hcd and
address 2
[1.382487] usb 2-1: New USB device found, idVendor=0ccd, idProduct=0099
[1.382490] usb 2-1: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
[1.382492] usb 2-1: Product: DVB-T TV Stick
[1.382494] usb 2-1: Manufacturer: ITE Technologies, Inc.
[1.385073] input: ITE Technologies, Inc. DVB-T TV Stick as
/devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.1/input/input1
[1.385147] generic-usb 0003:0CCD:0099.0001: input,hidraw0: USB HID
v1.01 Keyboard [ITE Technologies, Inc. DVB-T TV Stick] on
usb-:00:1d.7-1 input1
[5.045527] usbcore: registered new interface driver dvb_usb_it913x
[5.147276] it913x: Chip Version=01 Chip Type=9135
[5.147524] it913x: Firmware Version 33684956
[5.148649] it913x: Remote HID mode NOT SUPPORTED
[5.149024] it913x: Dual mode=3 Tuner Type=0
[5.149028] usb 2-1: dvb_usbv2: found a 'ITE 9135(9006) Generic' in
warm state
[5.149077] usb 2-1: dvb_usbv2: will pass the complete MPEG2
transport stream to the software demuxer
[5.149307] DVB: registering new adapter (ITE 9135(9006) Generic)
[5.174907] usb 1-4: dvb_usbv2: downloading firmware from file
'dvb-usb-af9015.fw'
[5.241934] usb 1-4: dvb_usbv2: found a 'AverMedia AVerTV Volar Black
HD (A850)' in warm state
[5.614827] usb 1-4: dvb_usbv2: will pass the complete MPEG2
transport stream to the software demuxer
[5.614866] DVB: registering new adapter (AverMedia AVerTV Volar
Black HD (A850))
[5.710026] af9013: firmware version 4.95.0.0
[5.712151] DVB: registering adapter 1 frontend 0 (Afatech AF9013)...
[5.813139] MXL5005S: Attached at address 0xc6
[5.818896] usb 1-4: dvb_usbv2: 'AverMedia AVerTV Volar Black HD
(A850)' successfully initialized and connected
[7.266161] usb 2-1: dvb_usbv2: 2nd usb_bulk_msg() failed=-110
[7.266247] it913x-fe: ADF table value:00
[9.267200] usb 2-1: dvb_usbv2: 2nd usb_bulk_msg() failed=-110
[   11.267153] usb 2-1: dvb_usbv2: 2nd usb_bulk_msg() failed=-110
[   13.267250] usb 2-1: dvb_usbv2: 2nd usb_bulk_msg() failed=-110
[   15.267089] usb 2-1: dvb_usbv2: 2nd usb_bulk_msg() failed=-110
[   17.267162] usb 2-1: dvb_usbv2: 2nd usb_bulk_msg() failed=-110
[   19.267139] usb 2-1: dvb_usbv2: 2nd usb_bulk_msg() failed=-110
[   19.267218] it913x-fe: Crystal Frequency :1200 Adc Frequency
:2025 ADC X2: 01
[   19.267296] usb 2-1: dvb_usbv2: 'ITE 9135(9006) Generic' error while
loading driver (-19)
[   19.267472] usb 2-1: dvb_usbv2: 'ITE 9135(9006) Generic' successfully
deinitialized and disconnected
---

I'm unfortunately not able to rewrite the driver, but I'm willing to
provide any information about the device to help its correct
identification. Here is what lsusb yields :
---
Bus 002 Device 003: ID 0ccd:0099 TerraTec Electronic GmbH
Device Descriptor:
   bLength18
   bDescriptorType 1
   bcdUSB   2.00
   bDeviceClass0 (Defined at Interface level)
   bDeviceSubClass 0
   bDeviceProtocol 0
   bMaxPacketSize064
   idVendor   0x0ccd TerraTec Electronic GmbH
   idProduct  0x0099
   bcdDevice2.00
   iManufacturer   1 ITE Technologies, Inc.
   iProduct2 DVB-T TV Stick
   iSerial 0
   bNumConfigurations  1
   Configuration Descriptor:
 bLength 9
 bDescriptorType 2
 wTotalLength   71
 bNumInterfaces  2
 bConfigurationValue 1
 iConfiguration  0
 bmAttributes 0x80
   (B

Re: [git:v4l-dvb/for_v3.7] [media] add LNA support for DVB API

2012-09-28 Thread Antti Palosaari

On 09/28/2012 08:07 PM, Hans Verkuil wrote:

On Fri September 28 2012 17:30:05 Mauro Carvalho Chehab wrote:

Em Fri, 28 Sep 2012 16:21:35 +0200
Hans Verkuil  escreveu:


On Fri September 28 2012 14:43:32 Hans Verkuil wrote:

Hi Antti,

Mauro asked me to look into LNA as well, in particular how this could be done
on the analog side as well.


Thanks for that!



While reading through this patch I noticed that the new property was added to
dtv_property_process_set, but not to dtv_property_process_get. Can you look
into that and add 'get' support for this property?


It's a sign of insanity when you start replying to your own email, but so
be it :-)


:)



I've been thinking how this can be implemented in such a way that it works
well in all the various board/tuner configurations.

First, the property should be cached in dtv_frontend_properties, that way
tuners with a built-in LNA can use it. The initial value should be AUTO,
I guess.

The property_process_set code changes to:

case DTV_LNA:
if (fe->ops.set_lna)
r = fe->ops.set_lna(fe, tvp->u.data);
if (!r)
c->lna = tvp->u.data;
break;

Tuners can now check the c->lna value when set_params is called and take the
appropriate steps if they have a built-in LNA.

To be able to access the LNA from the V4L2 side you would need to add two
new tuner ops in include/media/v4l2-subdev.h:

int (*g_lna)(struct v4l2_subdev *sd, u32 *lna);
int (*s_lna)(struct v4l2_subdev *sd, u32 lna);

The tuner-core.c driver can implement these ops to get and set c->lna 
accordingly.

A menu control would be needed to actually change the LNA.

The code that handles that control would have to call a board-specific function
if necessary (if the LNA is on the board), and call the tuner's s_lna op 
otherwise.



Makes sense.


The only question is whether the digital and analog APIs should share the same

LNA setting or keep different LNA states for each.

So if I call DTV_LNA to set the LNA, and then check the LNA control value from 
V4L2,
should the two match? Or should we keep separate states and whenever you select
digital or analog mode the LNA is updated with the corresponding LNA value for 
that
mode.

The latter is a bit more work (struct analog_parameters should probably be 
extended
with an LNA value), but I do think it is a cleaner solution.


I think they both should share the same LNA state, as this depends on the 
physical
connection (e. g. if the antenna has LNA; if the signal reception is weak or 
strong
with that particular antenna).


I am not sure if the LNA work on the analog side should be done without having
hardware that actually uses it, but at least the LNA support on the digital side
should be done in such a way that it can be extended for analog as well.


There are several saa7134 hardware with LNA support. I have one of such boards
here, although never needed to dig into the LNA stuff on it.


I'll wait until Antti makes the necessary changes on the digital side, after 
that
I'll see if I can make a patch for the analog part, and post that. There is an
outside chance that I have a board with an LNA as well: for ivtv there were 
issues
with a Samsung TCPN 2121P30A tuner where the LNA had to be turned on or off 
manually
(it should have been automatic but due to a hardware bug that didn't work). This
was never supported in ivtv, but this would make a good test case.

The only problem is that I don't know if I still have that card or if I gave it
to Andy. I think it went to him, actually.


Hans, your changes moving lna to property cache is fine for my eyes. I 
can change it if you wish, but maybe Sunday or next week


I dropped get operation originally as I wanted to keep workload small on 
that time. Also there was some other design issues, like one I selected 
AUTO as minimum possible value to leave space for extending possible 
values (both attenuation and gain). For now it is just on/off, but there 
is existing LNAs having more gain levels, not to mention VGAs and LNAs 
integrated to RF-tuners. Other design issue was units. Gains are 
measured as units of decibels, but I decided to use device specific 
steps instead of making some mechanism to enumerate supported gain levels.


Here is some discussion behind that LNA.

http://www.spinics.net/lists/linux-media/msg50132.html
http://www.spinics.net/lists/linux-media/msg50133.html
http://www.spinics.net/lists/linux-media/msg50139.html

http://blog.palosaari.fi/2012/07/patch-rfc-add-lna-support-for-dvb-api.html

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


Re: qv4l2-bug / libv4lconvert API issue

2012-09-28 Thread Frank Schäfer
Hi,

Am 27.09.2012 21:41, schrieb Hans de Goede:
> Hi,
>
> On 09/27/2012 03:20 PM, Frank Schäfer wrote:
>
> 
>
>>> What you've found is a qv4l2 bug (do you have the latest version?)
>>
>> Of course, I'm using the latest developer version.
>>
>> Even if this is just a qv4l2-bug: how do you want to fix it without
>> removing the format selction feature ?
>
> Well, if qv4l2 can only handle rgb24 data, then it should gray out the
> format selection (fixing it at rgb24) when not in raw mode.

So you say "just remove this feature from qv4l2".
I prefer fixing the library / API instead.

>
> v4lconvert_convert should only be called with
> src_fmt and dest_fmt parameters which are the result of a
> v4lconvert_try_format call, which clearly is not the case here!

Why ? Because our library code is broken ? ;)
Is this important restriction documented somewhere ?


>
>>
>>> one
>>> is supposed to either use libv4l2, or do raw device access and then
>>> call libv4lconvert directly.
>>
>> Even when using libv4lconvert only, multiple frame conversions are still
>> causing the same trouble.
>
> True, but doing multiple conversions on one frame is just crazy ...

Well, I would say "not necessary in most cases". But I can certainly
think of use cases (other than what qv4l2 does).
At least it should be possible and I think this is what application
programmers expect when using a conversion function from a library.

>
>> Hans, first of all, I would like to say that my intention is not to
>> savage your work.
>> I know API design and maintanance is very difficult and you are doing a
>> great job.
>> Things like this just happen and we have to make the best out of it.
>
> I will gladly admit that since libv4lconvert has organically grown
> things like flipping and software processing, the API is no longer
> ideal :)

So let's improve it ! :)

>
>>
>> But saying that libv4l2 and libv4lconvert can't be used at the same
>> (although they are separate public libraries) and that
>> v4lconvert_convert() may only be called once per frame seems to me like
>> a - I would say "weird" - reinterpretation of the API...
>> I don't think this is what applications currently expect (qv4l2 doesn't
>> ;) ) and at least this would need public clarification.
>
> Using the 2 at the same time never was the intention libv4lconvert
> lies *beneath* libv4l2 in the stack. 

Yeah, sure.

> Using them both at the same time
> would be like using some high level file io API, while at the same
> making lowlevel seek / read / write calls on the underlying fd and
> then expecting things to behave consistently. 00.9% of all apps should
> (and do) use the "highlevel" libv4l2 API. Some testing / developer
> apps like qv4l2 use libv4lconvert directly.

The problem here is, that we actually have TWO high level APIs which
interact in a - let's call it "unfortunate" - way.
This interaction is not clear for the users (due to the transparent
processing stuff) and it doesn't match not what users expect.
But I think we can fix it and gain some nice extra features as a bonus.

> And I must admit that
> I've considered simple making the libv4lconvert API private at times.

:D
That would certainly make things consistent ;)

>
>>
>> So let's see if there is a possibility to fix the issue by improving the
>> libraries without breaking the API.
>>
>> What about the following solution:
>> - make v4lconvert_convert_pixfmt() and v4lconvert_crop() public
>> functions and fix qv4l2 to use them instead of v4lconvert_convert()
>> - also make the flip and rotation functions (v4lconvert_flip(),
>> v4lconvert_rotate90()) publicly available
>
> That would need some careful review of their API's but after that yes
> that should be doable.
>
>> - modify libv4l2 to call v4lconvert_convert_pixfmt() and the
>> flip+rotation+crop functions instead of v4lconvert_convert()
> >
>> - fix v4lconvert_convert() to not do transparent image flipping/rotation
>> (means => call v4lconvert_convert_pixfmt() and v4lconvert_crop() only).
>
> Erm, no, have you looked at v4lconvert_convert it does a lot
> of magic with figuring out how much intermediate buffers it needs
> (skipping steps where possible), caches those buffers rather then
> re-alloc
> them every frame, etc.
>
> Making it do less means loosing some chances for optimization, and
> frankly
> it works well. I don't see why we would need some do some stuff but
> not all
> function when we also offer all the separate steps for users who want
> them.

Did you notice the mail I've sent a few minutes later ? ;)
I agree, we have to keep it as is but should mark it as deprecated.

>
> Also I still consider the rotate 90 for pac7302 part of the pixfmt
> conversion,
> this is something specific to how these cameras encode the picture, not
> a generic thing.

Yes, but why not make it a generic feature ? Would be nice to have.
(ever had a webcam with a clamp socket ?)
But this is just about a side effect, lets concentrate on the main issue.

>
>> For API-clean-u

Re: [git:v4l-dvb/for_v3.7] [media] add LNA support for DVB API

2012-09-28 Thread Hans Verkuil
On Fri September 28 2012 17:30:05 Mauro Carvalho Chehab wrote:
> Em Fri, 28 Sep 2012 16:21:35 +0200
> Hans Verkuil  escreveu:
> 
> > On Fri September 28 2012 14:43:32 Hans Verkuil wrote:
> > > Hi Antti,
> > > 
> > > Mauro asked me to look into LNA as well, in particular how this could be 
> > > done
> > > on the analog side as well.
> 
> Thanks for that!
> 
> > > 
> > > While reading through this patch I noticed that the new property was 
> > > added to
> > > dtv_property_process_set, but not to dtv_property_process_get. Can you 
> > > look
> > > into that and add 'get' support for this property?
> > 
> > It's a sign of insanity when you start replying to your own email, but so
> > be it :-)
> 
> :)
> 
> > 
> > I've been thinking how this can be implemented in such a way that it works
> > well in all the various board/tuner configurations.
> > 
> > First, the property should be cached in dtv_frontend_properties, that way
> > tuners with a built-in LNA can use it. The initial value should be AUTO,
> > I guess.
> > 
> > The property_process_set code changes to:
> > 
> > case DTV_LNA:
> > if (fe->ops.set_lna)
> > r = fe->ops.set_lna(fe, tvp->u.data);
> > if (!r)
> > c->lna = tvp->u.data;
> > break;
> > 
> > Tuners can now check the c->lna value when set_params is called and take the
> > appropriate steps if they have a built-in LNA.
> >
> > To be able to access the LNA from the V4L2 side you would need to add two
> > new tuner ops in include/media/v4l2-subdev.h:
> > 
> > int (*g_lna)(struct v4l2_subdev *sd, u32 *lna);
> > int (*s_lna)(struct v4l2_subdev *sd, u32 lna);
> > 
> > The tuner-core.c driver can implement these ops to get and set c->lna 
> > accordingly.
> > 
> > A menu control would be needed to actually change the LNA.
> > 
> > The code that handles that control would have to call a board-specific 
> > function
> > if necessary (if the LNA is on the board), and call the tuner's s_lna op 
> > otherwise.
> > 
> 
> Makes sense.
> 
> > > The only question is whether the digital and analog APIs should share the 
> > > same
> > LNA setting or keep different LNA states for each.
> > 
> > So if I call DTV_LNA to set the LNA, and then check the LNA control value 
> > from V4L2,
> > should the two match? Or should we keep separate states and whenever you 
> > select
> > digital or analog mode the LNA is updated with the corresponding LNA value 
> > for that
> > mode.
> > 
> > The latter is a bit more work (struct analog_parameters should probably be 
> > extended
> > with an LNA value), but I do think it is a cleaner solution.
> 
> I think they both should share the same LNA state, as this depends on the 
> physical
> connection (e. g. if the antenna has LNA; if the signal reception is weak or 
> strong
> with that particular antenna).
> 
> > I am not sure if the LNA work on the analog side should be done without 
> > having
> > hardware that actually uses it, but at least the LNA support on the digital 
> > side
> > should be done in such a way that it can be extended for analog as well.
> 
> There are several saa7134 hardware with LNA support. I have one of such boards
> here, although never needed to dig into the LNA stuff on it.

I'll wait until Antti makes the necessary changes on the digital side, after 
that
I'll see if I can make a patch for the analog part, and post that. There is an
outside chance that I have a board with an LNA as well: for ivtv there were 
issues
with a Samsung TCPN 2121P30A tuner where the LNA had to be turned on or off 
manually
(it should have been automatic but due to a hardware bug that didn't work). This
was never supported in ivtv, but this would make a good test case.

The only problem is that I don't know if I still have that card or if I gave it
to Andy. I think it went to him, actually.

Regards,

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


Error when doing build of media modules: WARNING: "snd_tea575x_init" [drivers/media/radio/radio-shark.ko] undefined!

2012-09-28 Thread Marcos Souza
Just giving a proper subject


-- Forwarded message --
From: Marcos Souza 
Date: 2012/9/28
Subject: Build
To: linux-media@vger.kernel.org, linux-ker...@vger.kernel.org


Hi media guys,

After try to build the media drivers with some radios enabled, I got this error:

marcos@tux:/mnt/dados/gitroot/linux$ make M=drivers/media
  Building modules, stage 2.
  MODPOST 21 modules
WARNING: "snd_tea575x_init" [drivers/media/radio/radio-shark.ko] undefined!
WARNING: "snd_tea575x_exit" [drivers/media/radio/radio-shark.ko] undefined!
WARNING: "snd_tea575x_init" [drivers/media/radio/radio-maxiradio.ko] undefined!
WARNING: "snd_tea575x_exit" [drivers/media/radio/radio-maxiradio.ko] undefined!

I saw that there is a EXPORT_SYMBOL of these functions in the file
sound/i2c/other/tea575x-tuner.c

But, I don't know how to find this...

Can someone show me how can I fix this?

Thanks since now!

--
Att,

Marcos Paulo de Souza
Acadêmico de Ciencia da Computação - FURB - SC
Github: https://github.com/marcosps/
"Uma vida sem desafios é uma vida sem razão"
"A life without challenges, is a non reason life"


-- 
Att,

Marcos Paulo de Souza
Acadêmico de Ciencia da Computação - FURB - SC
Github: https://github.com/marcosps/
"Uma vida sem desafios é uma vida sem razão"
"A life without challenges, is a non reason life"
--
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] usb id addition for Terratec Cinergy T Stick Dual rev. 2

2012-09-28 Thread Damien Bally

 > I will NACK that initially because that USB ID already used by AF9015

driver. You have to explain / study what happens when AF9015 driver
claims that device same time.



Hi Antti

With the Cinergy stick alone, dvb_usb_af9015 is predictably loaded, but 
doesn't prevent dvb_usb_it913x from working nicely.


If an afatech 9015 stick is connected, such as an AverTV Volar Black HD 
(A850), it will be recognized and doesn't affect the other device.


*But* it runs into trouble if the two devices were connected at bootup, 
or if the Cinergy stick is inserted after the other one :

---
[1.264018] usb 2-1: new high speed USB device using ehci_hcd and 
address 2

[1.382487] usb 2-1: New USB device found, idVendor=0ccd, idProduct=0099
[1.382490] usb 2-1: New USB device strings: Mfr=1, Product=2, 
SerialNumber=0

[1.382492] usb 2-1: Product: DVB-T TV Stick
[1.382494] usb 2-1: Manufacturer: ITE Technologies, Inc.
[1.385073] input: ITE Technologies, Inc. DVB-T TV Stick as 
/devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.1/input/input1
[1.385147] generic-usb 0003:0CCD:0099.0001: input,hidraw0: USB HID 
v1.01 Keyboard [ITE Technologies, Inc. DVB-T TV Stick] on 
usb-:00:1d.7-1 input1

[5.045527] usbcore: registered new interface driver dvb_usb_it913x
[5.147276] it913x: Chip Version=01 Chip Type=9135
[5.147524] it913x: Firmware Version 33684956
[5.148649] it913x: Remote HID mode NOT SUPPORTED
[5.149024] it913x: Dual mode=3 Tuner Type=0
[5.149028] usb 2-1: dvb_usbv2: found a 'ITE 9135(9006) Generic' in 
warm state
[5.149077] usb 2-1: dvb_usbv2: will pass the complete MPEG2 
transport stream to the software demuxer

[5.149307] DVB: registering new adapter (ITE 9135(9006) Generic)
[5.174907] usb 1-4: dvb_usbv2: downloading firmware from file 
'dvb-usb-af9015.fw'
[5.241934] usb 1-4: dvb_usbv2: found a 'AverMedia AVerTV Volar Black 
HD (A850)' in warm state
[5.614827] usb 1-4: dvb_usbv2: will pass the complete MPEG2 
transport stream to the software demuxer
[5.614866] DVB: registering new adapter (AverMedia AVerTV Volar 
Black HD (A850))

[5.710026] af9013: firmware version 4.95.0.0
[5.712151] DVB: registering adapter 1 frontend 0 (Afatech AF9013)...
[5.813139] MXL5005S: Attached at address 0xc6
[5.818896] usb 1-4: dvb_usbv2: 'AverMedia AVerTV Volar Black HD 
(A850)' successfully initialized and connected

[7.266161] usb 2-1: dvb_usbv2: 2nd usb_bulk_msg() failed=-110
[7.266247] it913x-fe: ADF table value   :00
[9.267200] usb 2-1: dvb_usbv2: 2nd usb_bulk_msg() failed=-110
[   11.267153] usb 2-1: dvb_usbv2: 2nd usb_bulk_msg() failed=-110
[   13.267250] usb 2-1: dvb_usbv2: 2nd usb_bulk_msg() failed=-110
[   15.267089] usb 2-1: dvb_usbv2: 2nd usb_bulk_msg() failed=-110
[   17.267162] usb 2-1: dvb_usbv2: 2nd usb_bulk_msg() failed=-110
[   19.267139] usb 2-1: dvb_usbv2: 2nd usb_bulk_msg() failed=-110
[   19.267218] it913x-fe: Crystal Frequency :1200 Adc Frequency 
:2025 ADC X2: 01
[   19.267296] usb 2-1: dvb_usbv2: 'ITE 9135(9006) Generic' error while 
loading driver (-19)
[   19.267472] usb 2-1: dvb_usbv2: 'ITE 9135(9006) Generic' successfully 
deinitialized and disconnected

---

I'm unfortunately not able to rewrite the driver, but I'm willing to 
provide any information about the device to help its correct 
identification. Here is what lsusb yields :

---
Bus 002 Device 003: ID 0ccd:0099 TerraTec Electronic GmbH
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize064
  idVendor   0x0ccd TerraTec Electronic GmbH
  idProduct  0x0099
  bcdDevice2.00
  iManufacturer   1 ITE Technologies, Inc.
  iProduct2 DVB-T TV Stick
  iSerial 0
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   71
bNumInterfaces  2
bConfigurationValue 1
iConfiguration  0
bmAttributes 0x80
  (Bus Powered)
MaxPower  500mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   4
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  0
  bInterfaceProtocol  0
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer 

Re: tda18271 driver power consumption

2012-09-28 Thread Antti Palosaari

On 09/28/2012 02:43 PM, Mauro Carvalho Chehab wrote:

Em Thu, 27 Sep 2012 17:58:24 -0400
Michael Krufky  escreveu:


On Thu, Sep 27, 2012 at 5:38 PM, Antti Palosaari  wrote:

On 09/28/2012 12:20 AM, Michael Krufky wrote:



Mike, There is other problem too. PCTV 520e, which is Em28xx + DRX-K +
TDA18271, fails to attach tuner now. Tuner is wired behind DRX-K I2C bus.
TDA18271 driver does very much I/O during attach and I2C error is raised
during attach now. Earlier it worked as DRX-K firmware was downloaded before
tuner was attached, but now both DRX-K fw download and tuner attach happens
same time leading that error.


Why is the DRX-K firmware downloading at the same time as tuner
attach?  Shouldn't the demod attach be finished before the tuner
attach begins?


Michael,

What happens is that udev changes forced drivers to load firmware 
asynchronously,
as, otherwise, udev won't load any firmware at all. Also, there's no warranty 
that
the firmware will be loaded on 2 seconds or so (Anti's hack were to add a 2 
seconds
wait after drxk atttach, to wait for firmware load).


IMHO whole current DRX-K FW is broken by design.
1) if fw is not really needed it should not be loaded on attach() 
instead first use case at .init()
2) if fw is needed then it must be loaded and wait chip is up and 
running and after that return from attach()


When you done it asynchronously like that, there is big you hit more 
problems depending on hardware configuration etc.


I explained that earlier too. But lets take more "real world" example.

There is USB DVB-S device. USB-bridge needs first firmware in order to 
offer I2C adapter. We need USB-bridge I2C-adapter to probe demodulator 
which sits on bridge I2C-bus. After demodulator is found we need to 
download firmware fir demodulator in order to find out tuner. Tuner sits 
behind demod I2C-bus. OK, download fw and start demod => get access for 
demod I2C-bus. Then probe used tuner. Download FW for tuner in order to 
get access for tuner GPIOs which are in that case controlled by tuner 
firmware. Finally there is LNB voltage controller which is controlled by 
tuner GPIO. We ask tuner firmware to disable LNB voltage supply.


Quite worst possible scenario, but highly possible. And it cannot be 
performed until firmware are loaded for each chip one by one.


The only place this kind "asynchronous" hack is allowed is bridge driver 
- leaving the rest as those are. And my real opinion is that this kind 
of functionality does not belong to drivers at all but somewhere more 
lower levels like USB/PCI core routines.



What I suspect is that tda18271 init is being interruped in the middle, by the
drxk firmware load. If this is the case, the solution is clean and quick: just
use the new i2c_lock_adapter() way to lock the I2C bus to tda18271 during the
critical part of the code where the register init happens.




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


Re: [PATCH 4/5] reservation: cross-device reservation support

2012-09-28 Thread Maarten Lankhorst
Op 28-09-12 17:29, Thomas Hellström schreef:
> On 9/28/12 2:43 PM, Maarten Lankhorst wrote:
>> This adds support for a generic reservations framework that can be
>> hooked up to ttm and dma-buf and allows easy sharing of reservations
>> across devices.
>>
>> The idea is that a dma-buf and ttm object both will get a pointer
>> to a struct reservation_object, which has to be reserved before
>> anything is done with the buffer.
> "Anything is done with the buffer" should probably be rephrased, as different 
> members of the buffer struct
> may be protected by different locks. It may not be practical or even possible 
> to
> protect all buffer members with reservation.
Agreed.
>> Some followup patches are needed in ttm so the lru_lock is no longer
>> taken during the reservation step. This makes the lockdep annotation
>> patch a lot more useful, and the assumption that the lru lock protects
>> atomic removal off the lru list will fail soon, anyway.
> As previously discussed, I'm unfortunately not prepared to accept removal of 
> the reserve-lru atomicity
>  into the TTM code at this point.
> The current code is based on this assumption and removing it will end up with
> efficiencies, breaking the delayed delete code and probably a locking 
> nightmare when trying to write
> new TTM code.
The lru lock removal patch fixed the delayed delete code, it really is not 
different from the current
situation. In fact it is more clear without the guarantee what various parts 
are trying to protect.

Nothing prevents you from holding the lru_lock while trylocking,
leaving that guarantee intact for that part. Can you really just review
the patch and tell me where it breaks and/or makes the code unreadable?

See my preemptive reply to patch 1/5 for details. I would prefer you
followup there. :-)

~Maarten

--
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:v4l-dvb/for_v3.7] [media] add LNA support for DVB API

2012-09-28 Thread Mauro Carvalho Chehab
Em Fri, 28 Sep 2012 16:21:35 +0200
Hans Verkuil  escreveu:

> On Fri September 28 2012 14:43:32 Hans Verkuil wrote:
> > Hi Antti,
> > 
> > Mauro asked me to look into LNA as well, in particular how this could be 
> > done
> > on the analog side as well.

Thanks for that!

> > 
> > While reading through this patch I noticed that the new property was added 
> > to
> > dtv_property_process_set, but not to dtv_property_process_get. Can you look
> > into that and add 'get' support for this property?
> 
> It's a sign of insanity when you start replying to your own email, but so
> be it :-)

:)

> 
> I've been thinking how this can be implemented in such a way that it works
> well in all the various board/tuner configurations.
> 
> First, the property should be cached in dtv_frontend_properties, that way
> tuners with a built-in LNA can use it. The initial value should be AUTO,
> I guess.
> 
> The property_process_set code changes to:
> 
>   case DTV_LNA:
>   if (fe->ops.set_lna)
>   r = fe->ops.set_lna(fe, tvp->u.data);
>   if (!r)
>   c->lna = tvp->u.data;
>   break;
> 
> Tuners can now check the c->lna value when set_params is called and take the
> appropriate steps if they have a built-in LNA.
>
> To be able to access the LNA from the V4L2 side you would need to add two
> new tuner ops in include/media/v4l2-subdev.h:
> 
>   int (*g_lna)(struct v4l2_subdev *sd, u32 *lna);
>   int (*s_lna)(struct v4l2_subdev *sd, u32 lna);
> 
> The tuner-core.c driver can implement these ops to get and set c->lna 
> accordingly.
> 
> A menu control would be needed to actually change the LNA.
> 
> The code that handles that control would have to call a board-specific 
> function
> if necessary (if the LNA is on the board), and call the tuner's s_lna op 
> otherwise.
> 

Makes sense.

> > The only question is whether the digital and analog APIs should share the 
> > same
> LNA setting or keep different LNA states for each.
> 
> So if I call DTV_LNA to set the LNA, and then check the LNA control value 
> from V4L2,
> should the two match? Or should we keep separate states and whenever you 
> select
> digital or analog mode the LNA is updated with the corresponding LNA value 
> for that
> mode.
> 
> The latter is a bit more work (struct analog_parameters should probably be 
> extended
> with an LNA value), but I do think it is a cleaner solution.

I think they both should share the same LNA state, as this depends on the 
physical
connection (e. g. if the antenna has LNA; if the signal reception is weak or 
strong
with that particular antenna).

> I am not sure if the LNA work on the analog side should be done without having
> hardware that actually uses it, but at least the LNA support on the digital 
> side
> should be done in such a way that it can be extended for analog as well.

There are several saa7134 hardware with LNA support. I have one of such boards
here, although never needed to dig into the LNA stuff on it.

> 
> Anyway, I think this approach would work for analog LNA support. Comments are
> welcome!

Regards,
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 4/5] reservation: cross-device reservation support

2012-09-28 Thread Thomas Hellström

On 9/28/12 2:43 PM, Maarten Lankhorst wrote:

This adds support for a generic reservations framework that can be
hooked up to ttm and dma-buf and allows easy sharing of reservations
across devices.

The idea is that a dma-buf and ttm object both will get a pointer
to a struct reservation_object, which has to be reserved before
anything is done with the buffer.
"Anything is done with the buffer" should probably be rephrased, as 
different members of the buffer struct
may be protected by different locks. It may not be practical or even 
possible to

protect all buffer members with reservation.


Some followup patches are needed in ttm so the lru_lock is no longer
taken during the reservation step. This makes the lockdep annotation
patch a lot more useful, and the assumption that the lru lock protects
atomic removal off the lru list will fail soon, anyway.
As previously discussed, I'm unfortunately not prepared to accept 
removal of the reserve-lru atomicity

 into the TTM code at this point.
The current code is based on this assumption and removing it will end up 
with
efficiencies, breaking the delayed delete code and probably a locking 
nightmare when trying to write

new TTM code.





Signed-off-by: Maarten Lankhorst 
---
  Documentation/DocBook/device-drivers.tmpl |2
  drivers/base/Makefile |2
  drivers/base/reservation.c|  285 +
  include/linux/reservation.h   |  179 ++
  4 files changed, 467 insertions(+), 1 deletion(-)
  create mode 100644 drivers/base/reservation.c
  create mode 100644 include/linux/reservation.h

diff --git a/Documentation/DocBook/device-drivers.tmpl 
b/Documentation/DocBook/device-drivers.tmpl
index ad14396..24e6e80 100644
--- a/Documentation/DocBook/device-drivers.tmpl
+++ b/Documentation/DocBook/device-drivers.tmpl
@@ -129,6 +129,8 @@ X!Edrivers/base/interface.c
  !Edrivers/base/fence.c
  !Iinclude/linux/fence.h
  !Iinclude/linux/seqno-fence.h
+!Edrivers/base/reservation.c
+!Iinclude/linux/reservation.h
  !Edrivers/base/dma-coherent.c
  !Edrivers/base/dma-mapping.c
   
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 0026563..f6f731d 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -10,7 +10,7 @@ obj-$(CONFIG_CMA) += dma-contiguous.o
  obj-y += power/
  obj-$(CONFIG_HAS_DMA) += dma-mapping.o
  obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o
-obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o fence.o
+obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o fence.o reservation.o
  obj-$(CONFIG_ISA) += isa.o
  obj-$(CONFIG_FW_LOADER)   += firmware_class.o
  obj-$(CONFIG_NUMA)+= node.o
diff --git a/drivers/base/reservation.c b/drivers/base/reservation.c
new file mode 100644
index 000..93e2d9f
--- /dev/null
+++ b/drivers/base/reservation.c
@@ -0,0 +1,285 @@
+/*
+ * Copyright (C) 2012 Canonical Ltd
+ *
+ * Based on bo.c which bears the following copyright notice,
+ * but is dual licensed:
+ *
+ * Copyright (c) 2006-2009 VMware, Inc., Palo Alto, CA., USA
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
+ * USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ **/
+/*
+ * Authors: Thomas Hellstrom 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+atomic64_t reservation_counter = ATOMIC64_INIT(1);
+EXPORT_SYMBOL(reservation_counter);
+
+int
+object_reserve(struct reservation_object *obj, bool intr, bool no_wait,
+  reservation_ticket_t *ticket)
+{
+   int ret;
+   u64 sequence = ticket ? ticket->seqno : 1;
+   u64 oldseq;
+
+   while (unlikely(oldseq = atomic64_cmpxchg(&obj->reserved, 0, 
sequence))) {
+
+   /**
+* Deadlock avoidance for multi-obj reserving.
+*/
+   if (sequence > 1 && oldseq > 1) {
+  

Re: omap3isp: wrong image after resizer with mt9v034 sensor

2012-09-28 Thread Enric Balletbò i Serra
Hi Laurent,

2012/9/28 Laurent Pinchart :
> Hi Enric,
>
> On Friday 28 September 2012 10:21:56 Enric Balletbò i Serra wrote:
>> 2012/9/28 Laurent Pinchart :
>> > On Thursday 27 September 2012 18:05:56 Enric Balletbò i Serra wrote:
>> >> 2012/9/27 Laurent Pinchart :
>> >> > On Wednesday 26 September 2012 16:15:35 Enric Balletbò i Serra wrote:
>> >> >> 2012/9/26 Laurent Pinchart :
>> >> >> > On Wednesday 26 September 2012 09:57:53 Enric Balletbò i Serra
>> >> >> > wrote:
>> >> >> >
>> >> >> > [snip]
>> >> >> >
>> >> >> >> You had reason. Checking the data lines of the camera bus with an
>> >> >> >> oscilloscope I see I had a problem, exactly in D8 /D9 data lines.
>> >> >> >
>> >> >> > I'm curious, how have you fixed that ?
>> >> >>
>> >> >> The board had a pull-down 4k7 resistor which I removed in these lines
>> >> >> (D8/D9). The board is prepared to accept sensors from 8 to 12 bits,
>> >> >> lines from D8 to D12 have a pull-down resistor to tie down the line by
>> >> >> default.
>> >> >>
>> >> >> With the oscilloscope I saw that D8/D9 had problems to go to high
>> >> >> level like you said, then I checked the schematic and I saw these
>> >> >> resistors.
>> >> >>
>> >> >> >> Now I can capture images but the color is still wrong, see the
>> >> >> >> following
>> >> >> >> image captured with pipeline SENSOR -> CCDC OUTPUT
>> >> >> >>
>> >> >> >> http://downloads.isee.biz/pub/files/patterns/img-01.pnm
>> >> >> >>
>> >> >> >> Now the image was converted using :
>> >> >> >> ./raw2rgbpnm -s 752x480 -f SGRBG10 img-01.bin
>> >> >> >> img-01.pnm
>> >> >> >>
>> >> >> >> And the raw data can be found here:
>> >> >> >> http://downloads.isee.biz/pub/files/patterns/img-01.bin
>> >> >> >>
>> >> >> >> Any idea where I can look ? Thanks.
>> >> >> >
>> >> >> > Your sensors produces BGGR data if I'm not mistaken, not GRBG.
>> >> >> > raw2rgbpnm doesn't support BGGR (yet), but the OMAP3 ISP preview
>> >> >> > engine
>> >> >> > can convert that to YUV since v3.5. Just make your sensor driver
>> >> >> > expose
>> >> >> > the right media bus format and configure the pipeline accordingly.
>> >> >>
>> >> >> The datasheet (p.10,11) says that the Pixel Color Pattern is as
>> >> >> follows.
>> >> >>
>> >> >> < direction
>> >> >> n  4321
>> >> >> .. GB GB GB GB
>> >> >> .. RG RG RG RG
>> >> >>
>> >> >> So seems you're right, if the first byte is on the right the sensor
>> >> >> produces BGGR. But for some reason the mt9v032 driver uses GRBG data.
>> >> >
>> >> > You can change the Bayer pattern by moving the crop rectangle. That how
>> >> > the mt9v032 driver ensures a GRBG pattern even though the first active
>> >> > pixel in the sensor array is a blue one. As the MT9V034 first active
>> >> > pixel
>> >> > is located at different coordinates you will have to modify the crop
>> >> > rectangle computation logic to get GRBG.
>> >>
>> >> Please, could you explain how to do this ? I'm a newbie into image
>> >> sensors world :-)
>> >
>> > Let's assume the following Bayer pattern (left to right and top to bottom
>> > direction).
>> >
>> >  | 1 2 3 4 5 6 7 8 ...
>> >
>> > --
>> > 1| G R G R G R G R ...
>> > 2| B G B G B G B G ...
>> > 3| G R G R G R G R ...
>> > 4| B G B G B G B G ...
>> > 5| G R G R G R G R ...
>> > 6| B G B G B G B G ...
>> > 7| G R G R G R G R ...
>> > 8| B G B G B G B G ...
>> > .| ...
>> >
>> > If you crop the (1,1)/4x4 rectangle from that sensor you will get
>> >
>> >  | 1 2 3 4
>> >
>> > --
>> > 1| G R G R
>> > 2| B G B G
>> > 3| G R G R
>> > 4| B G B G
>> >
>> > which is clearly a GRBG pattern. If you crop the (2,1)/4x4 rectangle you
>> > will get
>> >
>> >  | 2 3 4 5
>> >
>> > --
>> > 1| R G R G
>> > 2| G B G B
>> > 3| R G R G
>> > 4| G B G B
>> >
>> > which is now a RGGB pattern. The pattern you get out of your sensor thus
>> > depends on the crop rectangle position.
>>
>> Many thanks for the explanation. I'm learning a lot with your explanations
>> :-)
>> >> >> Maybe is related with following lines which writes register 0x0D Read
>> >> >> Mode (p.26,27) and presumably flips row or column bytes (not sure
>> >> >> about this I need to check)
>> >> >>
>> >> >> 334 /* Configure the window size and row/column bin */
>> >> >> 335 hratio = DIV_ROUND_CLOSEST(crop->width, format->width);
>> >> >> 336 vratio = DIV_ROUND_CLOSEST(crop->height, format->height);
>> >> >> 337
>> >> >> 338 ret = mt9v032_write(client, MT9V032_READ_MODE,
>> >> >> 339 (hratio - 1) <<
>> >> >> MT9V032_READ_MODE_ROW_BIN_SHIFT |
>> >> >> 340 (vratio - 1) <<
>> >> >> MT9V032_READ_MODE_COLUMN_BIN_SHIFT);
>> >> >>
>> >> >> Nonetheless, I changed the driver to configure for BGGR pattern. Using
>> >> >> the Sensor->CCDC->Preview->Resizer pipeline I captured the data with
>> >> >> yavta and converted using raw2rgbpnm program.
>> >> >>
>> >> >> ./raw2rgbpnm -s 752x48

[PATCH] tda18271-common: hold the I2C adapter during write transfers

2012-09-28 Thread Mauro Carvalho Chehab
The tda18271 datasheet says:

"The image rejection calibration and RF tracking filter
 calibration must be launched exactly as described in the
 flowchart, otherwise bad calibration or even blocking of the
 TDA18211HD can result making it impossible to communicate
 via the I2C-bus."

(yeah, tda18271 refers there to tda18211 - likely a typo at their
 datasheets)

That likely explains why sometimes tda18271 stops answering. That
is now happening more often on designs with drx-k chips, as the
firmware is now loaded asyncrousnly there.

While the above text doesn't explicitly tell that the I2C bus
couldn't be used by other devices during such initialization,
that seems to be a requirement there.

So, let's explicitly use the I2C lock there, avoiding I2C bus
share during those critical moments.

Compile-tested only. Please test.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/tuners/tda18271-common.c | 104 ++---
 1 file changed, 71 insertions(+), 33 deletions(-)

diff --git a/drivers/media/tuners/tda18271-common.c 
b/drivers/media/tuners/tda18271-common.c
index 221171e..18c77af 100644
--- a/drivers/media/tuners/tda18271-common.c
+++ b/drivers/media/tuners/tda18271-common.c
@@ -187,7 +187,8 @@ int tda18271_read_extended(struct dvb_frontend *fe)
return (ret == 2 ? 0 : ret);
 }
 
-int tda18271_write_regs(struct dvb_frontend *fe, int idx, int len)
+static int __tda18271_write_regs(struct dvb_frontend *fe, int idx, int len,
+   bool lock_i2c)
 {
struct tda18271_priv *priv = fe->tuner_priv;
unsigned char *regs = priv->tda18271_regs;
@@ -198,7 +199,6 @@ int tda18271_write_regs(struct dvb_frontend *fe, int idx, 
int len)
 
BUG_ON((len == 0) || (idx + len > sizeof(buf)));
 
-
switch (priv->small_i2c) {
case TDA18271_03_BYTE_CHUNK_INIT:
max = 3;
@@ -214,7 +214,19 @@ int tda18271_write_regs(struct dvb_frontend *fe, int idx, 
int len)
max = 39;
}
 
-   tda18271_i2c_gate_ctrl(fe, 1);
+
+   /*
+* If lock_i2c is true, it will take the I2C bus for tda18271 private
+* usage during the entire write ops, as otherwise, bad things could
+* happen.
+* During device init, several write operations will happen. So,
+* tda18271_init_regs controls the I2C lock directly,
+* disabling lock_i2c here.
+*/
+   if (lock_i2c) {
+   tda18271_i2c_gate_ctrl(fe, 1);
+   i2c_lock_adapter(priv->i2c_props.adap);
+   }
while (len) {
if (max > len)
max = len;
@@ -226,14 +238,17 @@ int tda18271_write_regs(struct dvb_frontend *fe, int idx, 
int len)
msg.len = max + 1;
 
/* write registers */
-   ret = i2c_transfer(priv->i2c_props.adap, &msg, 1);
+   ret = __i2c_transfer(priv->i2c_props.adap, &msg, 1);
if (ret != 1)
break;
 
idx += max;
len -= max;
}
-   tda18271_i2c_gate_ctrl(fe, 0);
+   if (lock_i2c) {
+   i2c_unlock_adapter(priv->i2c_props.adap);
+   tda18271_i2c_gate_ctrl(fe, 0);
+   }
 
if (ret != 1)
tda_err("ERROR: idx = 0x%x, len = %d, "
@@ -242,10 +257,16 @@ int tda18271_write_regs(struct dvb_frontend *fe, int idx, 
int len)
return (ret == 1 ? 0 : ret);
 }
 
+int tda18271_write_regs(struct dvb_frontend *fe, int idx, int len)
+{
+   return __tda18271_write_regs(fe, idx, len, true);
+}
+
 /*-*/
 
-int tda18271_charge_pump_source(struct dvb_frontend *fe,
-   enum tda18271_pll pll, int force)
+static int __tda18271_charge_pump_source(struct dvb_frontend *fe,
+enum tda18271_pll pll, int force,
+bool lock_i2c)
 {
struct tda18271_priv *priv = fe->tuner_priv;
unsigned char *regs = priv->tda18271_regs;
@@ -255,9 +276,16 @@ int tda18271_charge_pump_source(struct dvb_frontend *fe,
regs[r_cp] &= ~0x20;
regs[r_cp] |= ((force & 1) << 5);
 
-   return tda18271_write_regs(fe, r_cp, 1);
+   return __tda18271_write_regs(fe, r_cp, 1, lock_i2c);
+}
+
+int tda18271_charge_pump_source(struct dvb_frontend *fe,
+   enum tda18271_pll pll, int force)
+{
+   return __tda18271_charge_pump_source(fe, pll, force, true);
 }
 
+
 int tda18271_init_regs(struct dvb_frontend *fe)
 {
struct tda18271_priv *priv = fe->tuner_priv;
@@ -267,6 +295,13 @@ int tda18271_init_regs(struct dvb_frontend *fe)
i2c_adapter_id(priv->i2c_props.adap),
priv->i2c_props.addr);
 
+   /*
+* Don't let any other I2C transfer to happen at adapter during init,
+* as those could cau

Re: [git:v4l-dvb/for_v3.7] [media] add LNA support for DVB API

2012-09-28 Thread Hans Verkuil
On Fri September 28 2012 14:43:32 Hans Verkuil wrote:
> Hi Antti,
> 
> Mauro asked me to look into LNA as well, in particular how this could be done
> on the analog side as well.
> 
> While reading through this patch I noticed that the new property was added to
> dtv_property_process_set, but not to dtv_property_process_get. Can you look
> into that and add 'get' support for this property?

It's a sign of insanity when you start replying to your own email, but so
be it :-)

I've been thinking how this can be implemented in such a way that it works
well in all the various board/tuner configurations.

First, the property should be cached in dtv_frontend_properties, that way
tuners with a built-in LNA can use it. The initial value should be AUTO,
I guess.

The property_process_set code changes to:

case DTV_LNA:
if (fe->ops.set_lna)
r = fe->ops.set_lna(fe, tvp->u.data);
if (!r)
c->lna = tvp->u.data;
break;

Tuners can now check the c->lna value when set_params is called and take the
appropriate steps if they have a built-in LNA.

To be able to access the LNA from the V4L2 side you would need to add two
new tuner ops in include/media/v4l2-subdev.h:

int (*g_lna)(struct v4l2_subdev *sd, u32 *lna);
int (*s_lna)(struct v4l2_subdev *sd, u32 lna);

The tuner-core.c driver can implement these ops to get and set c->lna 
accordingly.

A menu control would be needed to actually change the LNA.

The code that handles that control would have to call a board-specific function
if necessary (if the LNA is on the board), and call the tuner's s_lna op 
otherwise.

The only question is whether the digital and analog APIs should share the same
LNA setting or keep different LNA states for each.

So if I call DTV_LNA to set the LNA, and then check the LNA control value from 
V4L2,
should the two match? Or should we keep separate states and whenever you select
digital or analog mode the LNA is updated with the corresponding LNA value for 
that
mode.

The latter is a bit more work (struct analog_parameters should probably be 
extended
with an LNA value), but I do think it is a cleaner solution.

I am not sure if the LNA work on the analog side should be done without having
hardware that actually uses it, but at least the LNA support on the digital side
should be done in such a way that it can be extended for analog as well.

Anyway, I think this approach would work for analog LNA support. Comments are
welcome!

Regards,

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


[PATCH 2/2] drivers: media: video: Add support for Aptina ar0130 sensor

2012-09-28 Thread Prashanth Subramanya
This driver adds basic support for Aptina ar0130 1.2M sensor.

Changes for v2:
1: Include new test pattern control as pointed by Hans and Lad.
2: Remove soc_camera.h as suggested by Guennadi.
3: Change auto exposure control as pointed by Dan Rittersdorf.
4: Change incorrect return value as pointed by Nicolas.
5: Change crop and binning settings.

Signed-off-by: Prashanth Subramanya 
---
 drivers/media/video/Kconfig   |7 +
 drivers/media/video/Makefile  |1 +
 drivers/media/video/ar0130.c  | 1088 +
 drivers/media/video/ar0130_regs.h |  107 
 include/media/ar0130.h|   52 ++
 include/media/v4l2-chip-ident.h   |1 +
 6 files changed, 1256 insertions(+)
 create mode 100644 drivers/media/video/ar0130.c
 create mode 100644 drivers/media/video/ar0130_regs.h
 create mode 100644 include/media/ar0130.h

diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index c128fac..821c021 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -505,6 +505,13 @@ config VIDEO_VS6624
  To compile this driver as a module, choose M here: the
  module will be called vs6624.
 
+config VIDEO_AR0130
+   tristate "Aptina AR0130 support"
+   depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+   ---help---
+ This is a Video4Linux2 sensor-level driver for the Aptina
+ ar0130 1.2 Mpixel camera.
+
 config VIDEO_MT9M032
tristate "MT9M032 camera sensor support"
depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index b7da9fa..4f97e30 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -71,6 +71,7 @@ obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
 obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
 obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
 obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
+obj-$(CONFIG_VIDEO_AR0130) += ar0130.o
 obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o
 obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o
 obj-$(CONFIG_VIDEO_MT9T001) += mt9t001.o
diff --git a/drivers/media/video/ar0130.c b/drivers/media/video/ar0130.c
new file mode 100644
index 000..1fdbafa
--- /dev/null
+++ b/drivers/media/video/ar0130.c
@@ -0,0 +1,1088 @@
+/*
+ * drivers/media/video/ar0130.c
+ *
+ * Aptina AR0130 sensor driver
+ *
+ * Copyright (C) 2012 Aptina Imaging
+ *
+ * Contributor Prashanth Subramanya 
+ *
+ * Based on MT9P031 driver
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "ar0130_regs.h"
+
+#defineAR0130_ROW_START_MIN0
+#defineAR0130_ROW_START_MAX1280
+#defineAR0130_ROW_START_DEF0
+#defineAR0130_COLUMN_START_MIN 0
+#defineAR0130_COLUMN_START_MAX 960
+#defineAR0130_COLUMN_START_DEF 0
+#defineAR0130_WINDOW_HEIGHT_MIN360
+#defineAR0130_WINDOW_HEIGHT_MAX960
+#defineAR0130_WINDOW_HEIGHT_DEF960
+#defineAR0130_WINDOW_WIDTH_MIN 640
+#defineAR0130_WINDOW_WIDTH_MAX 1280
+#defineAR0130_WINDOW_WIDTH_DEF 1280
+
+#define AR0130_VGA_WIDTH   640
+#define AR0130_VGA_HEIGHT  480
+#define AR0130_ENABLE  1
+#define AR0130_DISABLE 0
+
+#define AR0130_CHIP_VERSION_REG0x3000
+#define AR0130_CHIP_ID 0x2402
+#define AR0130_RESET_REG   0x301A
+#define AR0130_STREAM_ON   0x10DC
+#define AR0130_STREAM_OFF  0x10D8
+#define AR0130_SEQ_PORT0x3086
+#define AR0130_SEQ_PORT_CTRL   0x3088
+#define AR0130_TEST_REG0x3070
+#defineAR0130_TEST_PATTERN_DISABLE 0x
+
+#define AR0130_DCDS_PROG_START_ADDR0x309E
+#define AR0130_ADC_BITS_6_70x30E4
+#define AR0130_ADC_BITS_4_50x30E2
+#define AR0130_ADC_BITS_2_30x30E0
+#define AR0130_ADC_CONFIG1 0x30E6
+#define AR0130_ADC_CONFIG2 0x30E8
+
+#define AR0130_VT_SYS_CLK_DIV  0x302C
+#define AR0130_VT_PIX_CLK_DIV  0x302A
+#define AR0130_PRE_PLL_CLK_D

Re: [PATCH 2/4] [media] marvell-ccic: core: add soc camera support on marvell-ccic mcam-core

2012-09-28 Thread Hans Verkuil
On Fri September 28 2012 15:47:20 Albert Wang wrote:
> From: Libin Yang 
> 
> This patch adds the support of Soc Camera on marvell-ccic mcam-core.
> The Soc Camera mode does not compatible with current mode.
> Only one mode can be used at one time.
> 
> To use Soc Camera, CONFIG_VIDEO_MMP_SOC_CAMERA should be defined.
> What's more, the platform driver should support Soc camera at the same time.
> 
> Also add MIPI interface and dual CCICs support in Soc Camera mode.
> 
> Signed-off-by: Albert Wang 
> Signed-off-by: Libin Yang 
> ---
>  drivers/media/platform/marvell-ccic/mcam-core.c | 1034 
> ++
>  drivers/media/platform/marvell-ccic/mcam-core.h |  126 +++-
>  2 files changed, 997 insertions(+), 163 deletions(-)
> 
> diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c 
> b/drivers/media/platform/marvell-ccic/mcam-core.c
> index ce2b7b4..4adb1ca 100755
> --- a/drivers/media/platform/marvell-ccic/mcam-core.c
> +++ b/drivers/media/platform/marvell-ccic/mcam-core.c

...

> +static int mcam_camera_querycap(struct soc_camera_host *ici,
> + struct v4l2_capability *cap)
> +{
> + struct v4l2_dbg_chip_ident id;
> + struct mcam_camera *mcam = ici->priv;
> + struct soc_camera_device *icd = mcam->icd;
> + struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
> + int ret = 0;
> +
> + cap->version = KERNEL_VERSION(0, 0, 5);

Don't fill in version. It's set to the kernel version automatically.

> + cap->capabilities = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING;

Please also set cap->device_caps. See the spec.

> + ret = v4l2_subdev_call(sd, core, g_chip_ident, &id);

Yuck. Don't abuse this. g_chip_ident is for debugging purposes only.

> + if (ret < 0) {
> + cam_err(mcam, "%s %d\n", __func__, __LINE__);
> + return ret;
> + }
> +
> + strcpy(cap->card, mcam->card_name);
> + strncpy(cap->driver, (const char *)&(id.ident), 4);

No, the name of the driver is the name of this module: marvell_ccic.
It's *not* the name of the sensor driver.

> +
> + return 0;
> +}

Regards,

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


Re: [PATCH 1/5] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER

2012-09-28 Thread Maarten Lankhorst
Hey,

Op 28-09-12 14:41, Maarten Lankhorst schreef:
> Documentation says that code requiring dma-buf should add it to
> select, so inline fallbacks are not going to be used. A link error
> will make it obvious what went wrong, instead of silently doing
> nothing at runtime.
>
  


The whole patch series is in my tree, I use stg so things might
move around, do not use for merging currently:

http://cgit.freedesktop.org/~mlankhorst/linux/log/?h=v10-wip

It contains everything in here plus the patches for ttm to make
it work, I use a old snapshot of drm-next + merge of nouveau as
base. Description of what the parts do:

Series to fix small api issues when moving over:

drm/ttm: Remove cpu_writers related code
drm/ttm: Add ttm_bo_is_reserved function
drm/radeon: Use ttm_bo_is_reserved
drm/vmwgfx: use ttm_bo_is_reserved

drm/vmwgfx: remove use of fence_obj_args
drm/ttm: remove sync_obj_arg
drm/ttm: remove sync_obj_arg from ttm_bo_move_accel_cleanup
drm/ttm: remove sync_arg entirely

drm/nouveau: unpin buffers before releasing to prevent lockdep warnings
drm/nouveau: add reservation to nouveau_bo_vma_del
drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep

Hey great, now we only have one user left for fence waiting before reserving,
lets fix that and remove fence lock:
ttm_bo_cleanup_refs_or_queue and ttm_bo_cleanup_refs have to reserve before
waiting, lets do it in the squash commit so we don't have to throw lock order
around everywhere:

drm/ttm: remove fence_lock

-- Up to this point should be mergeable now

Then we start working on lru_lock removal slightly, this means the lru
list no longer is empty but can contain only reserved buffers:

drm/ttm: do not check if list is empty in ttm_bo_force_list_clean
drm/ttm: move reservations for ttm_bo_cleanup_refs

-- Still mergeable up to this point, just fixes

Patch series from this email:
dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER
fence: dma-buf cross-device synchronization (v9)
seqno-fence: Hardware dma-buf implementation of fencing (v3)
reservation: cross-device reservation support
reservation: Add lockdep annotation and selftests

Now hook it up to drm/ttm in a few steps:
usage around reservations:
drm/ttm: make ttm reservation calls behave like reservation calls
drm/ttm: use dma_reservation api
dma-buf: use reservations
drm/ttm: allow drivers to pass custom dma_reservation_objects for a bo

then kill off the lru lock around reservation:
drm/ttm: remove lru_lock around ttm_bo_reserve
drm/ttm: simplify ttm_eu_*

The lru_lock removal patch removes the lock around lru_lock around the
reservation, this will break the assumption that items on the lru list
and swap list can always be reserved, and this gets patched up too.
Is there any part in ttm you disagree with? I believe that this 
is all mergeable, the lru_lock removal patch could be moved to before
the reservation parts, this might make merging easier, but I don't
think there is any ttm part of the series that are wrong on a conceptual
level.

~Maarten

--
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 4/4] [media] marvell-ccic: core: add 3 frame buffers support in DMA_CONTIG mode

2012-09-28 Thread Albert Wang
This patch adds support of 3 frame buffers in DMA-contiguous mode.

In current DMA_CONTIG mode, only 2 frame buffers can be supported.
Actually, Marvell CCIC can support at most 3 frame buffers.

Currently 2 frame buffers mode will be used by default.
To use 3 frame buffers mode, can do:
  define MAX_FRAME_BUFS 3
in mcam-core.h

Signed-off-by: Albert Wang 
---
 drivers/media/platform/marvell-ccic/mcam-core.c |   87 
++
 drivers/media/platform/marvell-ccic/mcam-core.h |   15 -
 2 files changed, 74 insertions(+), 28 deletions(-)

diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c 
b/drivers/media/platform/marvell-ccic/mcam-core.c
index 4adb1ca..a805246 100755
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
@@ -228,7 +228,7 @@ static inline struct mcam_vb_buffer *vb_to_mvb(struct 
vb2_buffer *vb)
 /*
  * Hand a completed buffer back to user space.
  */
-static void mcam_buffer_done(struct mcam_camera *cam, int frame,
+static void mcam_buffer_done(struct mcam_camera *cam, unsigned int frame,
struct vb2_buffer *vbuf)
 {
vbuf->v4l2_buf.bytesused = cam->pix_format.sizeimage;
@@ -255,7 +255,7 @@ static void mcam_buffer_done(struct mcam_camera *cam, int 
frame,
  */
 static void mcam_reset_buffers(struct mcam_camera *cam)
 {
-   int i;
+   unsigned int i;
 
cam->next_buf = -1;
for (i = 0; i < cam->nbufs; i++) {
@@ -306,7 +306,7 @@ static void mcam_ctlr_stop(struct mcam_camera *cam)
  */
 static int mcam_alloc_dma_bufs(struct mcam_camera *cam, int loadtime)
 {
-   int i;
+   unsigned int i;
 
mcam_set_config_needed(cam, 1);
if (loadtime)
@@ -347,7 +347,7 @@ static int mcam_alloc_dma_bufs(struct mcam_camera *cam, int 
loadtime)
 
 static void mcam_free_dma_bufs(struct mcam_camera *cam)
 {
-   int i;
+   unsigned int i;
 
for (i = 0; i < cam->nbufs; i++) {
dma_free_coherent(cam->dev, cam->dma_buf_size,
@@ -386,7 +386,7 @@ static void mcam_ctlr_dma_vmalloc(struct mcam_camera *cam)
 static void mcam_frame_tasklet(unsigned long data)
 {
struct mcam_camera *cam = (struct mcam_camera *) data;
-   int i;
+   unsigned int i;
unsigned long flags;
struct mcam_vb_buffer *buf;
 
@@ -434,7 +434,7 @@ static int mcam_check_dma_buffers(struct mcam_camera *cam)
return 0;
 }
 
-static void mcam_vmalloc_done(struct mcam_camera *cam, int frame)
+static void mcam_vmalloc_done(struct mcam_camera *cam, unsigned int frame)
 {
tasklet_schedule(&cam->s_tasklet);
 }
@@ -471,20 +471,39 @@ static inline int mcam_check_dma_buffers(struct 
mcam_camera *cam)
  * space.  In this way, we always have a buffer to DMA to and don't
  * have to try to play games stopping and restarting the controller.
  */
-static void mcam_set_contig_buffer(struct mcam_camera *cam, int frame)
+static void mcam_set_contig_buffer(struct mcam_camera *cam, unsigned int frame)
 {
struct mcam_vb_buffer *buf;
struct v4l2_pix_format *fmt = &cam->pix_format;
unsigned long flags = 0;
 
spin_lock_irqsave(&cam->list_lock, flags);
-   /*
-* If there are no available buffers, go into single mode
-*/
if (list_empty(&cam->buffers)) {
-   buf = cam->vb_bufs[frame ^ 0x1];
-   set_bit(CF_SINGLE_BUFFER, &cam->flags);
-   cam->frame_state.singles++;
+   /*
+* If there are no available buffers
+* go into single buffer mode
+*
+* If CCIC use Two Buffers mode
+* will use another remaining frame buffer
+* frame 0 -> buf 1
+* frame 1 -> buf 0
+*
+* If CCIC use Three Buffers mode
+* will use the 2rd remaining frame buffer
+* frame 0 -> buf 2
+* frame 1 -> buf 0
+* frame 2 -> buf 1
+*/
+   buf = cam->vb_bufs[(frame + (MAX_FRAME_BUFS - 1))
+   % MAX_FRAME_BUFS];
+   if (cam->frame_state.tribufs == 0)
+   cam->frame_state.tribufs++;
+   else {
+   set_bit(CF_SINGLE_BUFFER, &cam->flags);
+   cam->frame_state.singles++;
+   if (cam->frame_state.tribufs < 2)
+   cam->frame_state.tribufs++;
+   }
} else {
/*
 * OK, we have a buffer we can use.
@@ -493,17 +512,16 @@ static void mcam_set_contig_buffer(struct mcam_camera 
*cam, int frame)
queue);
list_del_init(&buf->queue);
clear_bit(CF_SINGLE_BUFFER, &cam->flags);
+   if (cam->frame_state.tribufs != (3 - MAX_FRAME_BUFS))
+   cam->frame_state.tribuf

[PATCH 3/4] [media] marvell-ccic: mmp: add soc camera support on marvell-ccic mmp-driver

2012-09-28 Thread Albert Wang
From: Libin Yang 

This patch adds the support of Soc Camera on marvell-ccic mmp-driver.
The Soc Camera mode does not compatible with current mode.
Only one mode can be used at one time.

To enable Soc Camera on mmp:
In Device Drivers --> Multimedia support:
  select Cameras/video grabbers support
Then in Video capture adapters --> V4L platform devices -->
Camera support on Marvell MMP:
  select Marvell MMP camera driver based on SOC_CAMERA
Also in Video capture adapters --> V4L platform devices:
  select SoC camera support
  select the relevant sensor in target platform

Also add MIPI interface and dual CCICs support in Soc Camera mode.

Signed-off-by: Albert Wang 
Signed-off-by: Libin Yang 
---
 drivers/media/platform/Makefile  |4 +-
 drivers/media/platform/marvell-ccic/Kconfig  |   22 +++
 drivers/media/platform/marvell-ccic/Makefile |1 +
 drivers/media/platform/marvell-ccic/mmp-driver.c |  253 
+++--
 include/media/mmp-camera.h|   13 ++
 5 files changed, 233 insertions(+), 60 deletions(-)

diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index b7da9fa..ca60607 100755
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -146,9 +146,6 @@ obj-$(CONFIG_VIDEO_M32R_AR_M64278) += arv.o
 
 obj-$(CONFIG_VIDEO_CX2341X) += cx2341x.o
 
-obj-$(CONFIG_VIDEO_CAFE_CCIC) += marvell-ccic/
-obj-$(CONFIG_VIDEO_MMP_CAMERA) += marvell-ccic/
-
 obj-$(CONFIG_VIDEO_VIA_CAMERA) += via-camera.o
 
 obj-$(CONFIG_VIDEO_OMAP3)  += omap3isp/
@@ -182,6 +179,7 @@ obj-$(CONFIG_VIDEO_MX1) += mx1_camera.o
 obj-$(CONFIG_VIDEO_MX2)+= mx2_camera.o
 obj-$(CONFIG_VIDEO_MX3)+= mx3_camera.o
 obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o
+obj-$(CONFIG_VIDEO_MARVELL_CCIC)   += marvell-ccic/
 obj-$(CONFIG_VIDEO_SH_MOBILE_CSI2) += sh_mobile_csi2.o
 obj-$(CONFIG_VIDEO_SH_MOBILE_CEU)  += sh_mobile_ceu_camera.o
 obj-$(CONFIG_VIDEO_OMAP1)  += omap1_camera.o
diff --git a/drivers/media/platform/marvell-ccic/Kconfig 
b/drivers/media/platform/marvell-ccic/Kconfig
index bf739e3..6e3eaa0 100755
--- a/drivers/media/platform/marvell-ccic/Kconfig
+++ b/drivers/media/platform/marvell-ccic/Kconfig
@@ -1,23 +1,45 @@
+config VIDEO_MARVELL_CCIC
+   tristate
+config VIDEO_MRVL_SOC_CAMERA
+   tristate
+
 config VIDEO_CAFE_CCIC
tristate "Marvell 88ALP01 (Cafe) CMOS Camera Controller support"
depends on PCI && I2C && VIDEO_V4L2
select VIDEO_OV7670
select VIDEOBUF2_VMALLOC
select VIDEOBUF2_DMA_CONTIG
+   select VIDEO_MARVELL_CCIC
---help---
  This is a video4linux2 driver for the Marvell 88ALP01 integrated
  CMOS camera controller.  This is the controller found on first-
  generation OLPC systems.
 
+choice
+   prompt "Camera support on Marvell MMP"
+   depends on ARCH_MMP && VIDEO_V4L2
+   optional
 config VIDEO_MMP_CAMERA
tristate "Marvell Armada 610 integrated camera controller support"
depends on ARCH_MMP && I2C && VIDEO_V4L2
select VIDEO_OV7670
select I2C_GPIO
select VIDEOBUF2_DMA_SG
+   select VIDEO_MARVELL_CCIC
---help---
  This is a Video4Linux2 driver for the integrated camera
  controller found on Marvell Armada 610 application
  processors (and likely beyond).  This is the controller found
  in OLPC XO 1.75 systems.
 
+config VIDEO_MMP_SOC_CAMERA
+   bool "Marvell MMP camera driver based on SOC_CAMERA"
+   depends on VIDEO_DEV && SOC_CAMERA && ARCH_MMP && VIDEO_V4L2
+   select VIDEOBUF2_DMA_CONTIG
+   select VIDEO_MARVELL_CCIC
+   select VIDEO_MRVL_SOC_CAMERA
+   ---help---
+ This is a Video4Linux2 driver for the Marvell Mobile Soc
+ PXA910/PXA688/PXA2128/PXA988 CCIC
+ (CMOS Camera Interface Controller)
+endchoice
diff --git a/drivers/media/platform/marvell-ccic/Makefile 
b/drivers/media/platform/marvell-ccic/Makefile
index 05a792c..d6ffd16 100755
--- a/drivers/media/platform/marvell-ccic/Makefile
+++ b/drivers/media/platform/marvell-ccic/Makefile
@@ -2,5 +2,6 @@ obj-$(CONFIG_VIDEO_CAFE_CCIC) += cafe_ccic.o
 cafe_ccic-y := cafe-driver.o mcam-core.o
 
 obj-$(CONFIG_VIDEO_MMP_CAMERA) += mmp_camera.o
+obj-$(CONFIG_VIDEO_MMP_SOC_CAMERA) += mmp_camera.o
 mmp_camera-y := mmp-driver.o mcam-core.o
 
diff --git a/drivers/media/platform/marvell-ccic/mmp-driver.c 
b/drivers/media/platform/marvell-ccic/mmp-driver.c
index c4c17fe..afdd702 100755
--- a/drivers/media/platform/marvell-ccic/mmp-driver.c
+++ b/drivers/media/platform/marvell-ccic/mmp-driver.c
@@ -4,6 +4,12 @@
  *
  * Copyright 2011 Jonathan Corbet 
  *
+ * History:
+ * Support Soc Camera
+ * Support MIPI interface and Dual CCICs in Soc Camera mode
+ * Sep-2012: Libin Yang 
+ *   Albert Wang 
+ *
  * This file may be distributed under the terms of the GN

[PATCH 2/4] [media] marvell-ccic: core: add soc camera support on marvell-ccic mcam-core

2012-09-28 Thread Albert Wang
From: Libin Yang 

This patch adds the support of Soc Camera on marvell-ccic mcam-core.
The Soc Camera mode does not compatible with current mode.
Only one mode can be used at one time.

To use Soc Camera, CONFIG_VIDEO_MMP_SOC_CAMERA should be defined.
What's more, the platform driver should support Soc camera at the same time.

Also add MIPI interface and dual CCICs support in Soc Camera mode.

Signed-off-by: Albert Wang 
Signed-off-by: Libin Yang 
---
 drivers/media/platform/marvell-ccic/mcam-core.c | 1034 
++
 drivers/media/platform/marvell-ccic/mcam-core.h |  126 +++-
 2 files changed, 997 insertions(+), 163 deletions(-)

diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c 
b/drivers/media/platform/marvell-ccic/mcam-core.c
index ce2b7b4..4adb1ca 100755
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
@@ -3,6 +3,12 @@
  * so it needs platform-specific support outside of the core.
  *
  * Copyright 2011 Jonathan Corbet cor...@lwn.net
+ *
+ * History:
+ * Support Soc Camera
+ * Support MIPI interface and Dual CCICs in Soc Camera mode
+ * Sep-2012: Libin Yang 
+ *   Albert Wang 
  */
 #include 
 #include 
@@ -27,16 +33,14 @@
 #include 
 #include 
 #include 
+#ifdef CONFIG_VIDEO_MRVL_SOC_CAMERA
+#include 
+#include 
+#endif
+#include 
 
 #include "mcam-core.h"
 
-/*
- * Basic frame stats - to be deleted shortly
- */
-static int frames;
-static int singles;
-static int delivered;
-
 #ifdef MCAM_MODE_VMALLOC
 /*
  * Internal DMA buffer management.  Since the controller cannot do S/G I/O,
@@ -100,10 +104,50 @@ MODULE_PARM_DESC(buffer_mode,
 #define CF_CONFIG_NEEDED 4 /* Must configure hardware */
 #define CF_SINGLE_BUFFER 5 /* Running with a single buffer */
 #define CF_SG_RESTART   6  /* SG restart needed */
+#define CF_FRAME_SOF0   7  /* Frame 0 started */
+#define CF_FRAME_SOF1   8
+#define CF_FRAME_SOF2   9
 
+#ifdef CONFIG_VIDEO_MRVL_SOC_CAMERA
+#define sensor_call(cam, o, f, args...) \
+   v4l2_subdev_call(soc_camera_to_subdev(cam->icd), o, f, ##args)
+#else
 #define sensor_call(cam, o, f, args...) \
v4l2_subdev_call(cam->sensor, o, f, ##args)
+#endif
 
+#ifdef CONFIG_VIDEO_MRVL_SOC_CAMERA
+static const struct soc_mbus_pixelfmt mcam_formats[] = {
+   {
+   .fourcc = V4L2_PIX_FMT_UYVY,
+   .name = "YUV422PACKED",
+   .bits_per_sample = 8,
+   .packing = SOC_MBUS_PACKING_2X8_PADLO,
+   .order = SOC_MBUS_ORDER_LE,
+   },
+   {
+   .fourcc = V4L2_PIX_FMT_YUV422P,
+   .name = "YUV422PLANAR",
+   .bits_per_sample = 8,
+   .packing = SOC_MBUS_PACKING_2X8_PADLO,
+   .order = SOC_MBUS_ORDER_LE,
+   },
+   {
+   .fourcc = V4L2_PIX_FMT_YUV420,
+   .name = "YUV420PLANAR",
+   .bits_per_sample = 12,
+   .packing = SOC_MBUS_PACKING_NONE,
+   .order = SOC_MBUS_ORDER_LE,
+   },
+   {
+   .fourcc = V4L2_PIX_FMT_YVU420,
+   .name = "YVU420PLANAR",
+   .bits_per_sample = 12,
+   .packing = SOC_MBUS_PACKING_NONE,
+   .order = SOC_MBUS_ORDER_LE,
+   },
+};
+#else
 static struct mcam_format_struct {
__u8 *desc;
__u32 pixelformat;
@@ -147,6 +191,7 @@ static struct mcam_format_struct *mcam_find_format(u32 
pixelformat)
/* Not found? Then return the first format. */
return mcam_formats;
 }
+#endif
 
 /*
  * The default format we use until somebody says otherwise.
@@ -175,19 +220,6 @@ struct mcam_dma_desc {
u32 segment_len;
 };
 
-/*
- * Our buffer type for working with videobuf2.  Note that the vb2
- * developers have decreed that struct vb2_buffer must be at the
- * beginning of this structure.
- */
-struct mcam_vb_buffer {
-   struct vb2_buffer vb_buf;
-   struct list_head queue;
-   struct mcam_dma_desc *dma_desc; /* Descriptor virtual address */
-   dma_addr_t dma_desc_pa; /* Descriptor physical address */
-   int dma_desc_nent;  /* Number of mapped descriptors */
-};
-
 static inline struct mcam_vb_buffer *vb_to_mvb(struct vb2_buffer *vb)
 {
return container_of(vb, struct mcam_vb_buffer, vb_buf);
@@ -226,8 +258,10 @@ static void mcam_reset_buffers(struct mcam_camera *cam)
int i;
 
cam->next_buf = -1;
-   for (i = 0; i < cam->nbufs; i++)
+   for (i = 0; i < cam->nbufs; i++) {
clear_bit(i, &cam->flags);
+   clear_bit(CF_FRAME_SOF0 + i, &cam->flags);
+   }
 }
 
 static inline int mcam_needs_config(struct mcam_camera *cam)
@@ -367,10 +401,10 @@ static void mcam_frame_tasklet(unsigned long data)
if (!test_bit(bufno, &cam->flags))
continue;
if (list_empty(&cam->buffers)) {
-   singles++;
+   cam->frame

[PATCH 1/4] [media] mmp: add register definition for marvell ccic

2012-09-28 Thread Albert Wang
From: Libin Yang 

This patch adds the definition of CCIC1/2 Clock Reset register address

Signed-off-by: Albert Wang 
Signed-off-by: Libin Yang 
---
 arch/arm/mach-mmp/include/mach/regs-apmu.h |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-mmp/include/mach/regs-apmu.h 
b/arch/arm/mach-mmp/include/mach/regs-apmu.h
index 7af8deb..f2cf231 100755
--- a/arch/arm/mach-mmp/include/mach/regs-apmu.h
+++ b/arch/arm/mach-mmp/include/mach/regs-apmu.h
@@ -16,7 +16,8 @@
 /* Clock Reset Control */
 #define APMU_IRE   APMU_REG(0x048)
 #define APMU_LCD   APMU_REG(0x04c)
-#define APMU_CCIC  APMU_REG(0x050)
+#define APMU_CCIC_RST  APMU_REG(0x050)
+#define APMU_CCIC2_RST APMU_REG(0x0f4)
 #define APMU_SDH0  APMU_REG(0x054)
 #define APMU_SDH1  APMU_REG(0x058)
 #define APMU_USB   APMU_REG(0x05c)
-- 
1.7.0.4

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


[PATCH 0/4] [media] marvell-ccic: add soc camera support on marvell-ccic

2012-09-28 Thread Albert Wang
The following patches series will add soc camera support on marvell-ccic

[PATCH 1/4] [media] mmp: add register definition for marvell ccic

[PATCH 2/4] [media] marvell-ccic: core: add soc camera support on marvell-ccic 
mcam-core

[PATCH 3/4] [media] marvell-ccic: mmp: add soc camera support on marvell-ccic 
mmp-driver

[PATCH 4/4] [media] marvell-ccic: core: add 3 frame buffers support in 
DMA_CONTIG mode


Thanks
Albert Wang

--
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] mt9v022: support required register settings in snapshot mode

2012-09-28 Thread Anatolij Gustschin
On Fri, 28 Sep 2012 15:30:33 +0200 (CEST)
Guennadi Liakhovetski  wrote:
...
> > Yes. But i.e. the driver calling the sub-device stream control function
> > on streamon knows that the normal mode is not supported and therefore it
> > calls this function with argument enable == 0, effectively setting the
> > snapshot mode.
> 
> Right, I thought you could be doing that... Well, on the one hand I should 
> be happy, that the problem is solved without driver modifications, OTOH 
> this isn't pretty... In fact this shouldn't work at all. After a 
> stream-off the buffer queue should be stopped too.

Yes, the capture driver stops its buffer queue on stream-off.

Thanks,
Anatolij
--
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] mt9v022: support required register settings in snapshot mode

2012-09-28 Thread Guennadi Liakhovetski
On Fri, 28 Sep 2012, Anatolij Gustschin wrote:

> Hi Guennadi,
> 
> On Fri, 28 Sep 2012 14:33:34 +0200 (CEST)
> Guennadi Liakhovetski  wrote:
> ...
> > > @@ -235,12 +238,32 @@ static int mt9v022_s_stream(struct v4l2_subdev *sd, 
> > > int enable)
> > >   struct i2c_client *client = v4l2_get_subdevdata(sd);
> > >   struct mt9v022 *mt9v022 = to_mt9v022(client);
> > >  
> > > - if (enable)
> > > + if (enable) {
> > >   /* Switch to master "normal" mode */
> > >   mt9v022->chip_control &= ~0x10;
> > > - else
> > > + if (is_mt9v022_rev3(mt9v022->chip_version) ||
> > > + is_mt9v024(mt9v022->chip_version)) {
> > > + /*
> > > +  * Unset snapshot mode specific settings: clear bit 9
> > > +  * and bit 2 in reg. 0x20 when in normal mode.
> > > +  */
> > > + if (reg_clear(client, MT9V022_REG32, 0x204))
> > > + return -EIO;
> > > + }
> > > + } else {
> > >   /* Switch to snapshot mode */
> > >   mt9v022->chip_control |= 0x10;
> > > + if (is_mt9v022_rev3(mt9v022->chip_version) ||
> > > + is_mt9v024(mt9v022->chip_version)) {
> > > + /*
> > > +  * Required settings for snapshot mode: set bit 9
> > > +  * (RST enable) and bit 2 (CR enable) in reg. 0x20
> > > +  * See TechNote TN0960 or TN-09-225.
> > > +  */
> > > + if (reg_set(client, MT9V022_REG32, 0x204))
> > > + return -EIO;
> > > + }
> > > + }
> > 
> > Do I understand it right, that now on mt9v022 rev.3 and mt9v024 you 
> > unconditionally added using REG32 for leaving the snapshot mode on 
> > streamon and entering it on streamoff. This should be ok in principle, 
> > since that's also what we're trying to do, using the CHIP_CONTROL 
> > register. But in your comment you say, that on some _systems_ you can only 
> > _operate_ in snapshot mode. I.e. the snapshot mode enabled during running 
> > streaming, right? Then how does this patch help you with that?
> 
> Yes. But i.e. the driver calling the sub-device stream control function
> on streamon knows that the normal mode is not supported and therefore it
> calls this function with argument enable == 0, effectively setting the
> snapshot mode.

Right, I thought you could be doing that... Well, on the one hand I should 
be happy, that the problem is solved without driver modifications, OTOH 
this isn't pretty... In fact this shouldn't work at all. After a 
stream-off the buffer queue should be stopped too. However, to properly 
implement this you'd have to add a new V4L2 control to switch into 
snapshot mode.

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


account got bounced at vger that might affect patch reviews

2012-09-28 Thread Mauro Carvalho Chehab
Dear developers,

Due to some temporary trouble, I was unable to receive emails from
linux-media, since 10 hours ago. As I use my IMAP box to check for
review e-mails, if you replied to an existing patch during that period
of time, and didn't answered it with a Nacked-by/Acked-by tag[1],
please ping me, as otherwise I might be applying a patch
without noticing to your comments.

Thank you!
Mauro

[1] patchwork properly handles those tags (and a few others, like tested-by
and reviewed-by), and joins those when patches are downloaded. As my main
resource when applying patches is patchwork, you don't need to worry if you
use those tags, as I'll see it, even if I loose your email.
--
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/5] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER

2012-09-28 Thread Daniel Vetter
On Fri, Sep 28, 2012 at 02:41:48PM +0200, Maarten Lankhorst wrote:
> Documentation says that code requiring dma-buf should add it to
> select, so inline fallbacks are not going to be used. A link error
> will make it obvious what went wrong, instead of silently doing
> nothing at runtime.
> 
> Signed-off-by: Maarten Lankhorst 

Reviewed-by: Daniel Vetter 

I think it'd be good if we could merge this for 3.7 ...
-Daniel

> ---
>  include/linux/dma-buf.h |   99 
> ---
>  1 file changed, 99 deletions(-)
> 
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index eb48f38..bd2e52c 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -156,7 +156,6 @@ static inline void get_dma_buf(struct dma_buf *dmabuf)
>   get_file(dmabuf->file);
>  }
>  
> -#ifdef CONFIG_DMA_SHARED_BUFFER
>  struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
>   struct device *dev);
>  void dma_buf_detach(struct dma_buf *dmabuf,
> @@ -184,103 +183,5 @@ int dma_buf_mmap(struct dma_buf *, struct 
> vm_area_struct *,
>unsigned long);
>  void *dma_buf_vmap(struct dma_buf *);
>  void dma_buf_vunmap(struct dma_buf *, void *vaddr);
> -#else
> -
> -static inline struct dma_buf_attachment *dma_buf_attach(struct dma_buf 
> *dmabuf,
> - struct device *dev)
> -{
> - return ERR_PTR(-ENODEV);
> -}
> -
> -static inline void dma_buf_detach(struct dma_buf *dmabuf,
> -   struct dma_buf_attachment *dmabuf_attach)
> -{
> - return;
> -}
> -
> -static inline struct dma_buf *dma_buf_export(void *priv,
> -  const struct dma_buf_ops *ops,
> -  size_t size, int flags)
> -{
> - return ERR_PTR(-ENODEV);
> -}
> -
> -static inline int dma_buf_fd(struct dma_buf *dmabuf, int flags)
> -{
> - return -ENODEV;
> -}
> -
> -static inline struct dma_buf *dma_buf_get(int fd)
> -{
> - return ERR_PTR(-ENODEV);
> -}
> -
> -static inline void dma_buf_put(struct dma_buf *dmabuf)
> -{
> - return;
> -}
> -
> -static inline struct sg_table *dma_buf_map_attachment(
> - struct dma_buf_attachment *attach, enum dma_data_direction write)
> -{
> - return ERR_PTR(-ENODEV);
> -}
> -
> -static inline void dma_buf_unmap_attachment(struct dma_buf_attachment 
> *attach,
> - struct sg_table *sg, enum dma_data_direction dir)
> -{
> - return;
> -}
> -
> -static inline int dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
> -size_t start, size_t len,
> -enum dma_data_direction dir)
> -{
> - return -ENODEV;
> -}
> -
> -static inline void dma_buf_end_cpu_access(struct dma_buf *dmabuf,
> -   size_t start, size_t len,
> -   enum dma_data_direction dir)
> -{
> -}
> -
> -static inline void *dma_buf_kmap_atomic(struct dma_buf *dmabuf,
> - unsigned long pnum)
> -{
> - return NULL;
> -}
> -
> -static inline void dma_buf_kunmap_atomic(struct dma_buf *dmabuf,
> -  unsigned long pnum, void *vaddr)
> -{
> -}
> -
> -static inline void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned long pnum)
> -{
> - return NULL;
> -}
> -
> -static inline void dma_buf_kunmap(struct dma_buf *dmabuf,
> -   unsigned long pnum, void *vaddr)
> -{
> -}
> -
> -static inline int dma_buf_mmap(struct dma_buf *dmabuf,
> -struct vm_area_struct *vma,
> -unsigned long pgoff)
> -{
> - return -ENODEV;
> -}
> -
> -static inline void *dma_buf_vmap(struct dma_buf *dmabuf)
> -{
> - return NULL;
> -}
> -
> -static inline void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
> -{
> -}
> -#endif /* CONFIG_DMA_SHARED_BUFFER */
>  
>  #endif /* __DMA_BUF_H__ */
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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] mt9v022: support required register settings in snapshot mode

2012-09-28 Thread Anatolij Gustschin
Hi Guennadi,

On Fri, 28 Sep 2012 14:33:34 +0200 (CEST)
Guennadi Liakhovetski  wrote:
...
> > @@ -235,12 +238,32 @@ static int mt9v022_s_stream(struct v4l2_subdev *sd, 
> > int enable)
> > struct i2c_client *client = v4l2_get_subdevdata(sd);
> > struct mt9v022 *mt9v022 = to_mt9v022(client);
> >  
> > -   if (enable)
> > +   if (enable) {
> > /* Switch to master "normal" mode */
> > mt9v022->chip_control &= ~0x10;
> > -   else
> > +   if (is_mt9v022_rev3(mt9v022->chip_version) ||
> > +   is_mt9v024(mt9v022->chip_version)) {
> > +   /*
> > +* Unset snapshot mode specific settings: clear bit 9
> > +* and bit 2 in reg. 0x20 when in normal mode.
> > +*/
> > +   if (reg_clear(client, MT9V022_REG32, 0x204))
> > +   return -EIO;
> > +   }
> > +   } else {
> > /* Switch to snapshot mode */
> > mt9v022->chip_control |= 0x10;
> > +   if (is_mt9v022_rev3(mt9v022->chip_version) ||
> > +   is_mt9v024(mt9v022->chip_version)) {
> > +   /*
> > +* Required settings for snapshot mode: set bit 9
> > +* (RST enable) and bit 2 (CR enable) in reg. 0x20
> > +* See TechNote TN0960 or TN-09-225.
> > +*/
> > +   if (reg_set(client, MT9V022_REG32, 0x204))
> > +   return -EIO;
> > +   }
> > +   }
> 
> Do I understand it right, that now on mt9v022 rev.3 and mt9v024 you 
> unconditionally added using REG32 for leaving the snapshot mode on 
> streamon and entering it on streamoff. This should be ok in principle, 
> since that's also what we're trying to do, using the CHIP_CONTROL 
> register. But in your comment you say, that on some _systems_ you can only 
> _operate_ in snapshot mode. I.e. the snapshot mode enabled during running 
> streaming, right? Then how does this patch help you with that?

Yes. But i.e. the driver calling the sub-device stream control function
on streamon knows that the normal mode is not supported and therefore it
calls this function with argument enable == 0, effectively setting the
snapshot mode.

Thanks,
Anatolij
--
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 4/5] reservation: cross-device reservation support

2012-09-28 Thread Maarten Lankhorst
This adds support for a generic reservations framework that can be
hooked up to ttm and dma-buf and allows easy sharing of reservations
across devices.

The idea is that a dma-buf and ttm object both will get a pointer
to a struct reservation_object, which has to be reserved before
anything is done with the buffer.

Some followup patches are needed in ttm so the lru_lock is no longer
taken during the reservation step. This makes the lockdep annotation
patch a lot more useful, and the assumption that the lru lock protects
atomic removal off the lru list will fail soon, anyway.

Signed-off-by: Maarten Lankhorst 
---
 Documentation/DocBook/device-drivers.tmpl |2 
 drivers/base/Makefile |2 
 drivers/base/reservation.c|  285 +
 include/linux/reservation.h   |  179 ++
 4 files changed, 467 insertions(+), 1 deletion(-)
 create mode 100644 drivers/base/reservation.c
 create mode 100644 include/linux/reservation.h

diff --git a/Documentation/DocBook/device-drivers.tmpl 
b/Documentation/DocBook/device-drivers.tmpl
index ad14396..24e6e80 100644
--- a/Documentation/DocBook/device-drivers.tmpl
+++ b/Documentation/DocBook/device-drivers.tmpl
@@ -129,6 +129,8 @@ X!Edrivers/base/interface.c
 !Edrivers/base/fence.c
 !Iinclude/linux/fence.h
 !Iinclude/linux/seqno-fence.h
+!Edrivers/base/reservation.c
+!Iinclude/linux/reservation.h
 !Edrivers/base/dma-coherent.c
 !Edrivers/base/dma-mapping.c
  
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 0026563..f6f731d 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -10,7 +10,7 @@ obj-$(CONFIG_CMA) += dma-contiguous.o
 obj-y  += power/
 obj-$(CONFIG_HAS_DMA)  += dma-mapping.o
 obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o
-obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o fence.o
+obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o fence.o reservation.o
 obj-$(CONFIG_ISA)  += isa.o
 obj-$(CONFIG_FW_LOADER)+= firmware_class.o
 obj-$(CONFIG_NUMA) += node.o
diff --git a/drivers/base/reservation.c b/drivers/base/reservation.c
new file mode 100644
index 000..93e2d9f
--- /dev/null
+++ b/drivers/base/reservation.c
@@ -0,0 +1,285 @@
+/*
+ * Copyright (C) 2012 Canonical Ltd
+ *
+ * Based on bo.c which bears the following copyright notice,
+ * but is dual licensed:
+ *
+ * Copyright (c) 2006-2009 VMware, Inc., Palo Alto, CA., USA
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
+ * USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ **/
+/*
+ * Authors: Thomas Hellstrom 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+atomic64_t reservation_counter = ATOMIC64_INIT(1);
+EXPORT_SYMBOL(reservation_counter);
+
+int
+object_reserve(struct reservation_object *obj, bool intr, bool no_wait,
+  reservation_ticket_t *ticket)
+{
+   int ret;
+   u64 sequence = ticket ? ticket->seqno : 1;
+   u64 oldseq;
+
+   while (unlikely(oldseq = atomic64_cmpxchg(&obj->reserved, 0, 
sequence))) {
+
+   /**
+* Deadlock avoidance for multi-obj reserving.
+*/
+   if (sequence > 1 && oldseq > 1) {
+   /**
+* We've already reserved this one.
+*/
+   if (unlikely(sequence == oldseq))
+   return -EDEADLK;
+   /**
+* Already reserved by a thread that will not back
+* off for us. We need to back off.
+*/
+   if (unlikely(sequence - oldseq < (1ULL << 63)))
+   return -EAGAIN;
+   }
+
+   if (no_wait)
+   return -EBUSY;
+
+ 

[PATCH 1/5] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER

2012-09-28 Thread Maarten Lankhorst
Documentation says that code requiring dma-buf should add it to
select, so inline fallbacks are not going to be used. A link error
will make it obvious what went wrong, instead of silently doing
nothing at runtime.

Signed-off-by: Maarten Lankhorst 
---
 include/linux/dma-buf.h |   99 ---
 1 file changed, 99 deletions(-)

diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index eb48f38..bd2e52c 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -156,7 +156,6 @@ static inline void get_dma_buf(struct dma_buf *dmabuf)
get_file(dmabuf->file);
 }
 
-#ifdef CONFIG_DMA_SHARED_BUFFER
 struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
struct device *dev);
 void dma_buf_detach(struct dma_buf *dmabuf,
@@ -184,103 +183,5 @@ int dma_buf_mmap(struct dma_buf *, struct vm_area_struct 
*,
 unsigned long);
 void *dma_buf_vmap(struct dma_buf *);
 void dma_buf_vunmap(struct dma_buf *, void *vaddr);
-#else
-
-static inline struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
-   struct device *dev)
-{
-   return ERR_PTR(-ENODEV);
-}
-
-static inline void dma_buf_detach(struct dma_buf *dmabuf,
- struct dma_buf_attachment *dmabuf_attach)
-{
-   return;
-}
-
-static inline struct dma_buf *dma_buf_export(void *priv,
-const struct dma_buf_ops *ops,
-size_t size, int flags)
-{
-   return ERR_PTR(-ENODEV);
-}
-
-static inline int dma_buf_fd(struct dma_buf *dmabuf, int flags)
-{
-   return -ENODEV;
-}
-
-static inline struct dma_buf *dma_buf_get(int fd)
-{
-   return ERR_PTR(-ENODEV);
-}
-
-static inline void dma_buf_put(struct dma_buf *dmabuf)
-{
-   return;
-}
-
-static inline struct sg_table *dma_buf_map_attachment(
-   struct dma_buf_attachment *attach, enum dma_data_direction write)
-{
-   return ERR_PTR(-ENODEV);
-}
-
-static inline void dma_buf_unmap_attachment(struct dma_buf_attachment *attach,
-   struct sg_table *sg, enum dma_data_direction dir)
-{
-   return;
-}
-
-static inline int dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
-  size_t start, size_t len,
-  enum dma_data_direction dir)
-{
-   return -ENODEV;
-}
-
-static inline void dma_buf_end_cpu_access(struct dma_buf *dmabuf,
- size_t start, size_t len,
- enum dma_data_direction dir)
-{
-}
-
-static inline void *dma_buf_kmap_atomic(struct dma_buf *dmabuf,
-   unsigned long pnum)
-{
-   return NULL;
-}
-
-static inline void dma_buf_kunmap_atomic(struct dma_buf *dmabuf,
-unsigned long pnum, void *vaddr)
-{
-}
-
-static inline void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned long pnum)
-{
-   return NULL;
-}
-
-static inline void dma_buf_kunmap(struct dma_buf *dmabuf,
- unsigned long pnum, void *vaddr)
-{
-}
-
-static inline int dma_buf_mmap(struct dma_buf *dmabuf,
-  struct vm_area_struct *vma,
-  unsigned long pgoff)
-{
-   return -ENODEV;
-}
-
-static inline void *dma_buf_vmap(struct dma_buf *dmabuf)
-{
-   return NULL;
-}
-
-static inline void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
-{
-}
-#endif /* CONFIG_DMA_SHARED_BUFFER */
 
 #endif /* __DMA_BUF_H__ */

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


[PATCH 5/5] reservation: Add lockdep annotation and selftests

2012-09-28 Thread Maarten Lankhorst
Signed-off-by: Maarten Lankhorst 

---

The self-tests will fail if the commit "lockdep: Check if nested
lock is actually held" from linux tip core/locking is not applied.
---
 drivers/base/reservation.c  |   46 +-
 include/linux/reservation.h |   29 +++-
 lib/Kconfig.debug   |1 
 lib/locking-selftest.c  |  353 +--
 4 files changed, 403 insertions(+), 26 deletions(-)

diff --git a/drivers/base/reservation.c b/drivers/base/reservation.c
index 93e2d9f..b8d4f4d 100644
--- a/drivers/base/reservation.c
+++ b/drivers/base/reservation.c
@@ -41,6 +41,18 @@
 atomic64_t reservation_counter = ATOMIC64_INIT(1);
 EXPORT_SYMBOL(reservation_counter);
 
+const char reservation_object_name[] = "reservation_object";
+EXPORT_SYMBOL(reservation_object_name);
+
+const char reservation_ticket_name[] = "reservation_ticket";
+EXPORT_SYMBOL(reservation_ticket_name);
+
+struct lock_class_key reservation_object_class;
+EXPORT_SYMBOL(reservation_object_class);
+
+struct lock_class_key reservation_ticket_class;
+EXPORT_SYMBOL(reservation_ticket_class);
+
 int
 object_reserve(struct reservation_object *obj, bool intr, bool no_wait,
   reservation_ticket_t *ticket)
@@ -49,6 +61,10 @@ object_reserve(struct reservation_object *obj, bool intr, 
bool no_wait,
u64 sequence = ticket ? ticket->seqno : 1;
u64 oldseq;
 
+   if (!no_wait)
+   mutex_acquire_nest(&obj->dep_map, 0, 0,
+  ticket ? &ticket->dep_map : NULL, _RET_IP_);
+
while (unlikely(oldseq = atomic64_cmpxchg(&obj->reserved, 0, 
sequence))) {
 
/**
@@ -58,14 +74,18 @@ object_reserve(struct reservation_object *obj, bool intr, 
bool no_wait,
/**
 * We've already reserved this one.
 */
-   if (unlikely(sequence == oldseq))
-   return -EDEADLK;
+   if (unlikely(sequence == oldseq)) {
+   ret = -EDEADLK;
+   goto fail;
+   }
/**
 * Already reserved by a thread that will not back
 * off for us. We need to back off.
 */
-   if (unlikely(sequence - oldseq < (1ULL << 63)))
-   return -EAGAIN;
+   if (unlikely(sequence - oldseq < (1ULL << 63))) {
+   ret = -EAGAIN;
+   goto fail;
+   }
}
 
if (no_wait)
@@ -74,9 +94,12 @@ object_reserve(struct reservation_object *obj, bool intr, 
bool no_wait,
ret = object_wait_unreserved(obj, intr);
 
if (unlikely(ret))
-   return ret;
+   goto fail;
}
 
+   if (no_wait)
+   mutex_acquire(&obj->dep_map, 0, 1, _RET_IP_);
+
/**
 * Wake up waiters that may need to recheck for deadlock,
 * if we decreased the sequence number.
@@ -84,6 +107,11 @@ object_reserve(struct reservation_object *obj, bool intr, 
bool no_wait,
wake_up_all(&obj->event_queue);
 
return 0;
+
+fail:
+   if (!no_wait)
+   mutex_release(&obj->dep_map, 1, _RET_IP_);
+   return ret;
 }
 EXPORT_SYMBOL(object_reserve);
 
@@ -105,6 +133,14 @@ void
 object_unreserve(struct reservation_object *obj,
 reservation_ticket_t *ticket)
 {
+   mutex_release(&obj->dep_map, 1, _RET_IP_);
+
+   if (!object_is_reserved(obj)) {
+#ifndef CONFIG_DEBUG_LOCKING_API_SELFTESTS
+   WARN_ON(1);
+#endif
+   return;
+   }
smp_mb();
atomic64_set(&obj->reserved, 0);
wake_up_all(&obj->event_queue);
diff --git a/include/linux/reservation.h b/include/linux/reservation.h
index 93280af..6fa0cdb 100644
--- a/include/linux/reservation.h
+++ b/include/linux/reservation.h
@@ -44,6 +44,10 @@
 #include 
 
 extern atomic64_t reservation_counter;
+extern const char reservation_object_name[];
+extern struct lock_class_key reservation_object_class;
+extern const char reservation_ticket_name[];
+extern struct lock_class_key reservation_ticket_class;
 
 struct reservation_object {
wait_queue_head_t event_queue;
@@ -53,10 +57,17 @@ struct reservation_object {
u32 fence_shared_count;
struct fence *fence_excl;
struct fence *fence_shared[BUF_MAX_SHARED_FENCE];
+
+#ifdef CONFIG_DEBUG_LOCK_ALLOC
+   struct lockdep_map dep_map;
+#endif
 };
 
 typedef struct reservation_ticket {
u64 seqno;
+#ifdef CONFIG_DEBUG_LOCK_ALLOC
+   struct lockdep_map dep_map;
+#endif
 } reservation_ticket_t;
 
 /**
@@ -73,11 +84,13 @@ struct reservation_entry {
unsigned long obj_shared;
 };
 
-
 static inline void
 __reservation_object_init(struct reservatio

[PATCH 2/5] fence: dma-buf cross-device synchronization (v9)

2012-09-28 Thread Maarten Lankhorst
A fence can be attached to a buffer which is being filled or consumed
by hw, to allow userspace to pass the buffer without waiting to another
device.  For example, userspace can call page_flip ioctl to display the
next frame of graphics after kicking the GPU but while the GPU is still
rendering.  The display device sharing the buffer with the GPU would
attach a callback to get notified when the GPU's rendering-complete IRQ
fires, to update the scan-out address of the display, without having to
wake up userspace.

A fence is transient, one-shot deal.  It is allocated and attached
to one or more dma-buf's.  When the one that attached it is done, with
the pending operation, it can signal the fence:
  + fence_signal()

To have a rough approximation whether a fence is fired, call:
  + fence_is_signaled()

The dma-buf-mgr handles tracking, and waiting on, the fences associated
with a dma-buf.

The one pending on the fence can add an async callback:
  + fence_add_callback()

The callback can optionally be cancelled with:
  + fence_remove_callback()

To wait synchronously, optionally with a timeout:
  + fence_wait()
  + fence_wait_timeout()

A default software-only implementation is provided, which can be used
by drivers attaching a fence to a buffer when they have no other means
for hw sync.  But a memory backed fence is also envisioned, because it
is common that GPU's can write to, or poll on some memory location for
synchronization.  For example:

  fence = custom_get_fence(...);
  if ((seqno_fence = to_seqno_fence(fence)) != NULL) {
dma_buf *fence_buf = fence->sync_buf;
get_dma_buf(fence_buf);

... tell the hw the memory location to wait ...
custom_wait_on(fence_buf, fence->seqno_ofs, fence->seqno);
  } else {
/* fall-back to sw sync * /
fence_add_callback(fence, my_cb);
  }

On SoC platforms, if some other hw mechanism is provided for synchronizing
between IP blocks, it could be supported as an alternate implementation
with it's own fence ops in a similar way.

To facilitate other non-sw implementations, the enable_signaling callback
can be used to keep track if a device not supporting hw sync is waiting
on the fence, and in this case should arrange to call fence_signal()
at some point after the condition has changed, to notify other devices
waiting on the fence.  If there are no sw waiters, this can be skipped to
avoid waking the CPU unnecessarily. The handler of the enable_signaling
op should take a refcount until the fence is signaled, then release its ref.

The intention is to provide a userspace interface (presumably via eventfd)
later, to be used in conjunction with dma-buf's mmap support for sw access
to buffers (or for userspace apps that would prefer to do their own
synchronization).

v1: Original
v2: After discussion w/ danvet and mlankhorst on #dri-devel, we decided
that dma-fence didn't need to care about the sw->hw signaling path
(it can be handled same as sw->sw case), and therefore the fence->ops
can be simplified and more handled in the core.  So remove the signal,
add_callback, cancel_callback, and wait ops, and replace with a simple
enable_signaling() op which can be used to inform a fence supporting
hw->hw signaling that one or more devices which do not support hw
signaling are waiting (and therefore it should enable an irq or do
whatever is necessary in order that the CPU is notified when the
fence is passed).
v3: Fix locking fail in attach_fence() and get_fence()
v4: Remove tie-in w/ dma-buf..  after discussion w/ danvet and mlankorst
we decided that we need to be able to attach one fence to N dma-buf's,
so using the list_head in dma-fence struct would be problematic.
v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
v6: [ Maarten Lankhorst ] I removed dma_fence_cancel_callback and some comments
about checking if fence fired or not. This is broken by design.
waitqueue_active during destruction is now fatal, since the signaller
should be holding a reference in enable_signalling until it signalled
the fence. Pass the original dma_fence_cb along, and call __remove_wait
in the dma_fence_callback handler, so that no cleanup needs to be
performed.
v7: [ Maarten Lankhorst ] Set cb->func and only enable sw signaling if
fence wasn't signaled yet, for example for hardware fences that may
choose to signal blindly.
v8: [ Maarten Lankhorst ] Tons of tiny fixes, moved __dma_fence_init to
header and fixed include mess. dma-fence.h now includes dma-buf.h
All members are now initialized, so kmalloc can be used for
allocating a dma-fence. More documentation added.
v9: Change compiler bitfields to flags, change return type of
enable_signaling to bool. Rework dma_fence_wait. Added
dma_fence_is_signaled and dma_fence_wait_timeout.
s/dma// and change exports to non GPL. Added fence_is_signaled and
fence_enable_sw_signaling calls, add ability to override def

[PATCH 3/5] seqno-fence: Hardware dma-buf implementation of fencing (v3)

2012-09-28 Thread Maarten Lankhorst
This type of fence can be used with hardware synchronization for simple
hardware that can block execution until the condition
(dma_buf[offset] - value) >= 0 has been met.

A software fallback still has to be provided in case the fence is used
with a device that doesn't support this mechanism. It is useful to expose
this for graphics cards that have an op to support this.

Some cards like i915 can export those, but don't have an option to wait,
so they need the software fallback.

I extended the original patch by Rob Clark.

v1: Original
v2: Renamed from bikeshed to seqno, moved into dma-fence.c since
not much was left of the file. Lots of documentation added.
v3: Use fence_ops instead of custom callbacks. Moved to own file
to avoid circular dependency between dma-buf.h and fence.h

Signed-off-by: Maarten Lankhorst 
---
 Documentation/DocBook/device-drivers.tmpl |1 
 drivers/base/fence.c  |   36 ++
 include/linux/seqno-fence.h   |  107 +
 3 files changed, 144 insertions(+)
 create mode 100644 include/linux/seqno-fence.h

diff --git a/Documentation/DocBook/device-drivers.tmpl 
b/Documentation/DocBook/device-drivers.tmpl
index 6f53fc0..ad14396 100644
--- a/Documentation/DocBook/device-drivers.tmpl
+++ b/Documentation/DocBook/device-drivers.tmpl
@@ -128,6 +128,7 @@ X!Edrivers/base/interface.c
 !Edrivers/base/dma-buf.c
 !Edrivers/base/fence.c
 !Iinclude/linux/fence.h
+!Iinclude/linux/seqno-fence.h
 !Edrivers/base/dma-coherent.c
 !Edrivers/base/dma-mapping.c
  
diff --git a/drivers/base/fence.c b/drivers/base/fence.c
index b90a09e..0a184b2 100644
--- a/drivers/base/fence.c
+++ b/drivers/base/fence.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static int __fence_signal(struct fence *fence)
 {
@@ -335,3 +336,38 @@ struct fence *fence_create(void *priv)
return fence;
 }
 EXPORT_SYMBOL(fence_create);
+
+static bool seqno_enable_signaling(struct fence *fence)
+{
+   struct seqno_fence *seqno_fence = to_seqno_fence(fence);
+   return seqno_fence->ops->enable_signaling(fence);
+}
+
+static bool seqno_signaled(struct fence *fence)
+{
+   struct seqno_fence *seqno_fence = to_seqno_fence(fence);
+   return seqno_fence->ops->signaled && seqno_fence->ops->signaled(fence);
+}
+
+static void seqno_release(struct fence *fence)
+{
+   struct seqno_fence *f = to_seqno_fence(fence);
+
+   if (f->ops->release)
+   f->ops->release(fence);
+   dma_buf_put(f->sync_buf);
+}
+
+static long seqno_wait(struct fence *fence, bool intr, signed long timeout)
+{
+   struct seqno_fence *f = to_seqno_fence(fence);
+   return f->ops->wait(fence, intr, timeout);
+}
+
+const struct fence_ops seqno_fence_ops = {
+   .enable_signaling = seqno_enable_signaling,
+   .signaled = seqno_signaled,
+   .wait = seqno_wait,
+   .release = seqno_release
+};
+EXPORT_SYMBOL_GPL(seqno_fence_ops);
diff --git a/include/linux/seqno-fence.h b/include/linux/seqno-fence.h
new file mode 100644
index 000..971cebe
--- /dev/null
+++ b/include/linux/seqno-fence.h
@@ -0,0 +1,107 @@
+/*
+ * seqno-fence, using a dma-buf to synchronize fencing
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Copyright (C) 2012 Canonical Ltd
+ * Authors:
+ *   Rob Clark 
+ *   Maarten Lankhorst 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * 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, see .
+ */
+
+#ifndef __SEQNO_FENCE_H__
+#define __SEQNO_FENCE_H__
+
+#include 
+#include 
+
+struct seqno_fence {
+   struct fence base;
+
+   const struct fence_ops *ops;
+   struct dma_buf *sync_buf;
+   uint32_t seqno_ofs;
+   uint32_t seqno;
+};
+
+extern const struct fence_ops seqno_fence_ops;
+
+/**
+ * to_seqno_fence - cast a fence to a seqno_fence
+ * @fence: fence to cast to a seqno_fence
+ *
+ * Returns NULL if the fence is not a seqno_fence,
+ * or the seqno_fence otherwise.
+ */
+static inline struct seqno_fence *
+to_seqno_fence(struct fence *fence)
+{
+   if (fence->ops != &seqno_fence_ops)
+   return NULL;
+   return container_of(fence, struct seqno_fence, base);
+}
+
+/**
+ * seqno_fence_init - initialize a seqno fence
+ * @fence: seqno_fence to initialize
+ * @sync_buf: buffer containing the memory location to signal on
+ * @seqno_ofs: the offset within @sync_buf
+ * @seqno: the sequence # to signal on
+ * @priv: value of priv member
+ * @ops: the fence_ops for operations on this seqno fenc

[PATCH 3/7] [media] ds3000: properly report register read errors

2012-09-28 Thread Rémi Cardona
This brings both ds3000_readreg() and ds3000_tuner_readreg() in line
with ds3000_writereg() and ds3000_tuner_writereg() respectively.

Signed-off-by: Rémi Cardona 
---
 drivers/media/dvb-frontends/ds3000.c |   11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/media/dvb-frontends/ds3000.c 
b/drivers/media/dvb-frontends/ds3000.c
index 474f26e..675 100644
--- a/drivers/media/dvb-frontends/ds3000.c
+++ b/drivers/media/dvb-frontends/ds3000.c
@@ -340,7 +340,7 @@ static int ds3000_readreg(struct ds3000_state *state, u8 
reg)
 
if (ret != 2) {
printk(KERN_ERR "%s: reg=0x%x(error=%d)\n", __func__, reg, ret);
-   return ret;
+   return -EREMOTEIO;
}
 
dprintk("%s: read reg 0x%02x, value 0x%02x\n", __func__, reg, b1[0]);
@@ -367,12 +367,15 @@ static int ds3000_tuner_readreg(struct ds3000_state 
*state, u8 reg)
}
};
 
-   ds3000_writereg(state, 0x03, 0x12);
-   ret = i2c_transfer(state->i2c, msg, 2);
+   ret = ds3000_writereg(state, 0x03, 0x12);
+   if (ret < 0) {
+   return -EREMOTEIO;
+   }
 
+   ret = i2c_transfer(state->i2c, msg, 2);
if (ret != 2) {
printk(KERN_ERR "%s: reg=0x%x(error=%d)\n", __func__, reg, ret);
-   return ret;
+   return -EREMOTEIO;
}
 
dprintk("%s: read reg 0x%02x, value 0x%02x\n", __func__, reg, b1[0]);
-- 
1.7.10.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 1/7] [media] ds3000: Declare MODULE_FIRMWARE usage

2012-09-28 Thread Rémi Cardona
Signed-off-by: Rémi Cardona 
---
 drivers/media/dvb-frontends/ds3000.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/dvb-frontends/ds3000.c 
b/drivers/media/dvb-frontends/ds3000.c
index 4c8ac26..46874c7 100644
--- a/drivers/media/dvb-frontends/ds3000.c
+++ b/drivers/media/dvb-frontends/ds3000.c
@@ -1310,3 +1310,4 @@ MODULE_DESCRIPTION("DVB Frontend module for Montage 
Technology "
"DS3000/TS2020 hardware");
 MODULE_AUTHOR("Konstantin Dimitrov");
 MODULE_LICENSE("GPL");
+MODULE_FIRMWARE(DS3000_DEFAULT_FIRMWARE);
-- 
1.7.10.4

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


[PATCH 5/7] [media] ds3000: properly report firmware probing issues

2012-09-28 Thread Rémi Cardona
ds3000_readreg() returns negative values in case of i2c failures. The
old code would simply return 0 when failing to read the 0xb2 register,
misleading ds3000_initfe() into believing that the firmware had been
correctly loaded.

Signed-off-by: Rémi Cardona 
---
 drivers/media/dvb-frontends/ds3000.c |7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/ds3000.c 
b/drivers/media/dvb-frontends/ds3000.c
index 162faaf..59184a8 100644
--- a/drivers/media/dvb-frontends/ds3000.c
+++ b/drivers/media/dvb-frontends/ds3000.c
@@ -395,8 +395,13 @@ static int ds3000_firmware_ondemand(struct dvb_frontend 
*fe)
 
dprintk("%s()\n", __func__);
 
-   if (ds3000_readreg(state, 0xb2) <= 0)
+   ret = ds3000_readreg(state, 0xb2);
+   if (ret == 0) {
+   /* Firmware already uploaded, skipping */
return ret;
+   } else if (ret < 0) {
+   return ret;
+   }
 
/* Load firmware */
/* request the firmware, this will block until someone uploads it */
-- 
1.7.10.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 4/7] [media] ds3000: bail out early on i2c failures during firmware load

2012-09-28 Thread Rémi Cardona
 - if kmalloc() returns NULL, we can return immediately without trying
   to kfree() a NULL pointer.
 - if i2c_transfer() fails, error out immediately instead of trying to
   upload the remaining bytes of the firmware.
 - the error code is then properly propagated down to ds3000_initfe().

Signed-off-by: Rémi Cardona 
---
 drivers/media/dvb-frontends/ds3000.c |   12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/media/dvb-frontends/ds3000.c 
b/drivers/media/dvb-frontends/ds3000.c
index 675..162faaf 100644
--- a/drivers/media/dvb-frontends/ds3000.c
+++ b/drivers/media/dvb-frontends/ds3000.c
@@ -280,15 +280,14 @@ static int ds3000_tuner_writereg(struct ds3000_state 
*state, int reg, int data)
 static int ds3000_writeFW(struct ds3000_state *state, int reg,
const u8 *data, u16 len)
 {
-   int i, ret = -EREMOTEIO;
+   int i, ret = 0;
struct i2c_msg msg;
u8 *buf;
 
buf = kmalloc(33, GFP_KERNEL);
if (buf == NULL) {
printk(KERN_ERR "Unable to kmalloc\n");
-   ret = -ENOMEM;
-   goto error;
+   return -ENOMEM;
}
 
*(buf) = reg;
@@ -308,8 +307,10 @@ static int ds3000_writeFW(struct ds3000_state *state, int 
reg,
printk(KERN_ERR "%s: write error(err == %i, "
"reg == 0x%02x\n", __func__, ret, reg);
ret = -EREMOTEIO;
+   goto error;
}
}
+   ret = 0;
 
 error:
kfree(buf);
@@ -426,6 +427,7 @@ static int ds3000_load_firmware(struct dvb_frontend *fe,
const struct firmware *fw)
 {
struct ds3000_state *state = fe->demodulator_priv;
+   int ret = 0;
 
dprintk("%s\n", __func__);
dprintk("Firmware is %zu bytes (%02x %02x .. %02x %02x)\n",
@@ -438,10 +440,10 @@ static int ds3000_load_firmware(struct dvb_frontend *fe,
/* Begin the firmware load process */
ds3000_writereg(state, 0xb2, 0x01);
/* write the entire firmware */
-   ds3000_writeFW(state, 0xb0, fw->data, fw->size);
+   ret = ds3000_writeFW(state, 0xb0, fw->data, fw->size);
ds3000_writereg(state, 0xb2, 0x00);
 
-   return 0;
+   return ret;
 }
 
 static int ds3000_set_voltage(struct dvb_frontend *fe, fe_sec_voltage_t 
voltage)
-- 
1.7.10.4

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


[PATCH 2/7] [media] ds3000: remove useless 'locking'

2012-09-28 Thread Rémi Cardona
Since b9bf2eafaad9c1ef02fb3db38c74568be601a43a, the function
ds3000_firmware_ondemand() is called only once during init. This
locking scheme may have been useful when the firmware was loaded at
each tune.

Furthermore, it looks like this 'lock' was put in to prevent concurrent
access (and not recursion as the comments suggest). However, this open-
coded mechanism is anything but race-free and should have used a proper
mutex.

Signed-off-by: Rémi Cardona 
---
 drivers/media/dvb-frontends/ds3000.c |9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/media/dvb-frontends/ds3000.c 
b/drivers/media/dvb-frontends/ds3000.c
index 46874c7..474f26e 100644
--- a/drivers/media/dvb-frontends/ds3000.c
+++ b/drivers/media/dvb-frontends/ds3000.c
@@ -233,7 +233,6 @@ struct ds3000_state {
struct i2c_adapter *i2c;
const struct ds3000_config *config;
struct dvb_frontend frontend;
-   u8 skip_fw_load;
/* previous uncorrected block counter for DVB-S2 */
u16 prevUCBS2;
 };
@@ -395,8 +394,6 @@ static int ds3000_firmware_ondemand(struct dvb_frontend *fe)
if (ds3000_readreg(state, 0xb2) <= 0)
return ret;
 
-   if (state->skip_fw_load)
-   return 0;
/* Load firmware */
/* request the firmware, this will block until someone uploads it */
printk(KERN_INFO "%s: Waiting for firmware upload (%s)...\n", __func__,
@@ -410,9 +407,6 @@ static int ds3000_firmware_ondemand(struct dvb_frontend *fe)
return ret;
}
 
-   /* Make sure we don't recurse back through here during loading */
-   state->skip_fw_load = 1;
-
ret = ds3000_load_firmware(fe, fw);
if (ret)
printk("%s: Writing firmware to device failed\n", __func__);
@@ -422,9 +416,6 @@ static int ds3000_firmware_ondemand(struct dvb_frontend *fe)
dprintk("%s: Firmware upload %s\n", __func__,
ret == 0 ? "complete" : "failed");
 
-   /* Ensure firmware is always loaded if required */
-   state->skip_fw_load = 0;
-
return ret;
 }
 
-- 
1.7.10.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 v3 0/7] ds3000/dw2102 improvements

2012-09-28 Thread Rémi Cardona
Hi all,

Here's hopefully the final round of patches for ds3000.

All of the patches have been rebased on top of today's staging/for_v3.7
branch.

Patches 1 through 4 are identical to the previous v2. Patches 5 and 6
are functionally identical, only the printk()s have been removed. Patch
7 is new, as we have recently gotten a few S480 cards from TeVii and we
were missing their firmware, and found modinfo to be lacking the info.

Thanks again for any review/comments.

Cheers,

Rémi Cardona

-- 
SmartJog | T: +33 1 5868 6229
27 Blvd Hippolyte Marquès, 94200 Ivry-sur-Seine, France
www.smartjog.com | a TDF Group company

--
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 7/7] [media] dw2102: Declare MODULE_FIRMWARE usage

2012-09-28 Thread Rémi Cardona
Signed-off-by: Rémi Cardona 
---
 drivers/media/usb/dvb-usb/dw2102.c |   36 ++--
 1 file changed, 26 insertions(+), 10 deletions(-)

diff --git a/drivers/media/usb/dvb-usb/dw2102.c 
b/drivers/media/usb/dvb-usb/dw2102.c
index 9382895..937c744 100644
--- a/drivers/media/usb/dvb-usb/dw2102.c
+++ b/drivers/media/usb/dvb-usb/dw2102.c
@@ -80,6 +80,15 @@
 #define DW2102_RC_QUERY (0x1a00)
 #define DW2102_LED_CTRL (0x1b00)
 
+#define DW2101_FIRMWARE "dvb-usb-dw2101.fw"
+#define DW2102_FIRMWARE "dvb-usb-dw2102.fw"
+#define DW2104_FIRMWARE "dvb-usb-dw2104.fw"
+#define DW3101_FIRMWARE "dvb-usb-dw3101.fw"
+#define S630_FIRMWARE   "dvb-usb-s630.fw"
+#define S660_FIRMWARE   "dvb-usb-s660.fw"
+#define P1100_FIRMWARE  "dvb-usb-p1100.fw"
+#define P7500_FIRMWARE  "dvb-usb-p7500.fw"
+
 #defineerr_str "did not find the firmware file. (%s) " \
"Please see linux/Documentation/dvb/ for more details " \
"on firmware-problems."
@@ -1478,13 +1487,12 @@ static int dw2102_load_firmware(struct usb_device *dev,
u8 reset;
u8 reset16[] = {0, 0, 0, 0, 0, 0, 0};
const struct firmware *fw;
-   const char *fw_2101 = "dvb-usb-dw2101.fw";
 
switch (dev->descriptor.idProduct) {
case 0x2101:
-   ret = request_firmware(&fw, fw_2101, &dev->dev);
+   ret = request_firmware(&fw, DW2101_FIRMWARE, &dev->dev);
if (ret != 0) {
-   err(err_str, fw_2101);
+   err(err_str, DW2101_FIRMWARE);
return ret;
}
break;
@@ -1586,7 +1594,7 @@ static int dw2102_load_firmware(struct usb_device *dev,
 static struct dvb_usb_device_properties dw2102_properties = {
.caps = DVB_USB_IS_AN_I2C_ADAPTER,
.usb_ctrl = DEVICE_SPECIFIC,
-   .firmware = "dvb-usb-dw2102.fw",
+   .firmware = DW2102_FIRMWARE,
.no_reconnect = 1,
 
.i2c_algo = &dw2102_serit_i2c_algo,
@@ -1641,7 +1649,7 @@ static struct dvb_usb_device_properties dw2102_properties 
= {
 static struct dvb_usb_device_properties dw2104_properties = {
.caps = DVB_USB_IS_AN_I2C_ADAPTER,
.usb_ctrl = DEVICE_SPECIFIC,
-   .firmware = "dvb-usb-dw2104.fw",
+   .firmware = DW2104_FIRMWARE,
.no_reconnect = 1,
 
.i2c_algo = &dw2104_i2c_algo,
@@ -1691,7 +1699,7 @@ static struct dvb_usb_device_properties dw2104_properties 
= {
 static struct dvb_usb_device_properties dw3101_properties = {
.caps = DVB_USB_IS_AN_I2C_ADAPTER,
.usb_ctrl = DEVICE_SPECIFIC,
-   .firmware = "dvb-usb-dw3101.fw",
+   .firmware = DW3101_FIRMWARE,
.no_reconnect = 1,
 
.i2c_algo = &dw3101_i2c_algo,
@@ -1739,7 +1747,7 @@ static struct dvb_usb_device_properties s6x0_properties = 
{
.caps = DVB_USB_IS_AN_I2C_ADAPTER,
.usb_ctrl = DEVICE_SPECIFIC,
.size_of_priv = sizeof(struct s6x0_state),
-   .firmware = "dvb-usb-s630.fw",
+   .firmware = S630_FIRMWARE,
.no_reconnect = 1,
 
.i2c_algo = &s6x0_i2c_algo,
@@ -1879,7 +1887,7 @@ static int dw2102_probe(struct usb_interface *intf,
return -ENOMEM;
/* copy default structure */
/* fill only different fields */
-   p1100->firmware = "dvb-usb-p1100.fw";
+   p1100->firmware = P1100_FIRMWARE;
p1100->devices[0] = d1100;
p1100->rc.legacy.rc_map_table = rc_map_tbs_table;
p1100->rc.legacy.rc_map_size = ARRAY_SIZE(rc_map_tbs_table);
@@ -1891,7 +1899,7 @@ static int dw2102_probe(struct usb_interface *intf,
kfree(p1100);
return -ENOMEM;
}
-   s660->firmware = "dvb-usb-s660.fw";
+   s660->firmware = S660_FIRMWARE;
s660->num_device_descs = 3;
s660->devices[0] = d660;
s660->devices[1] = d480_1;
@@ -1905,7 +1913,7 @@ static int dw2102_probe(struct usb_interface *intf,
kfree(s660);
return -ENOMEM;
}
-   p7500->firmware = "dvb-usb-p7500.fw";
+   p7500->firmware = P7500_FIRMWARE;
p7500->devices[0] = d7500;
p7500->rc.legacy.rc_map_table = rc_map_tbs_table;
p7500->rc.legacy.rc_map_size = ARRAY_SIZE(rc_map_tbs_table);
@@ -1949,3 +1957,11 @@ MODULE_DESCRIPTION("Driver for DVBWorld DVB-S 2101, 
2102, DVB-S2 2104,"
" Geniatech SU3000 devices");
 MODULE_VERSION("0.1");
 MODULE_LICENSE("GPL");
+MODULE_FIRMWARE(DW2101_FIRMWARE);
+MODULE_FIRMWARE(DW2102_FIRMWARE);
+MODULE_FIRMWARE(DW2104_FIRMWARE);
+MODULE_FIRMWARE(DW3101_FIRMWARE);
+MODULE_FIRMWARE(S630_FIRMWARE);
+MODULE_FIRMWARE(S660_FIRMWARE);
+MODULE_FIRMWARE(P1100_FIRMWARE);
+MODULE_FIRMWARE(P7500_FIRMWARE);
-- 
1.7.10.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 6/7] [media] ds3000: add module parameter to force firmware upload

2012-09-28 Thread Rémi Cardona
Signed-off-by: Rémi Cardona 
---
 drivers/media/dvb-frontends/ds3000.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/ds3000.c 
b/drivers/media/dvb-frontends/ds3000.c
index 59184a8..c66d731 100644
--- a/drivers/media/dvb-frontends/ds3000.c
+++ b/drivers/media/dvb-frontends/ds3000.c
@@ -30,6 +30,7 @@
 #include "ds3000.h"
 
 static int debug;
+static int force_fw_upload;
 
 #define dprintk(args...) \
do { \
@@ -396,7 +397,7 @@ static int ds3000_firmware_ondemand(struct dvb_frontend *fe)
dprintk("%s()\n", __func__);
 
ret = ds3000_readreg(state, 0xb2);
-   if (ret == 0) {
+   if (ret == 0 && force_fw_upload == 0) {
/* Firmware already uploaded, skipping */
return ret;
} else if (ret < 0) {
@@ -1307,6 +1308,9 @@ static struct dvb_frontend_ops ds3000_ops = {
 module_param(debug, int, 0644);
 MODULE_PARM_DESC(debug, "Activates frontend debugging (default:0)");
 
+module_param(force_fw_upload, int, 0644);
+MODULE_PARM_DESC(force_fw_upload, "Force firmware upload (default:0)");
+
 MODULE_DESCRIPTION("DVB Frontend module for Montage Technology "
"DS3000/TS2020 hardware");
 MODULE_AUTHOR("Konstantin Dimitrov");
-- 
1.7.10.4

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


Re: [PATCH 1/2] dm644x: replace the obsolete preset API by the timings API.

2012-09-28 Thread Prabhakar Lad
Hi Hans,

On Fri, Sep 28, 2012 at 6:22 PM, Hans Verkuil  wrote:
> Hi Prabhakar!
>
> On Fri September 28 2012 14:44:59 Prabhakar Lad wrote:
>> Hi Kevin,
>>
>> On Wed, Aug 8, 2012 at 6:00 PM, Prabhakar Lad  wrote:
>> > From: Hans Verkuil 
>> >
>> > Signed-off-by: Hans Verkuil 
>> > Signed-off-by: Lad, Prabhakar 
>> > Signed-off-by: Manjunath Hadli 
>> > ---
>> >  arch/arm/mach-davinci/board-dm644x-evm.c   |   15 ++--
>> >  arch/arm/mach-davinci/dm644x.c |   17 +---
>> >  drivers/media/video/davinci/vpbe.c |  110 
>> > 
>> >  drivers/media/video/davinci/vpbe_display.c |   60 +++
>> >  drivers/media/video/davinci/vpbe_venc.c|   25 +++---
>> >  include/media/davinci/vpbe.h   |   14 ++--
>> >  include/media/davinci/vpbe_types.h |8 +--
>> >  include/media/davinci/vpbe_venc.h  |2 +-
>> >  8 files changed, 111 insertions(+), 140 deletions(-)
>> >
>> Can you ACK this patch? Since this patch needs to go from Mauro's tree
>> due to changes in media drivers folder structure.
>>
>> Regards,
>> --Prabhakar Lad
>>
>
> ...
>
>> > -static int vpbe_s_dv_preset(struct vpbe_device *vpbe_dev,
>> > -struct v4l2_dv_preset *dv_preset)
>> > +static int vpbe_s_dv_timings(struct vpbe_device *vpbe_dev,
>> > +struct v4l2_dv_timings *dv_timings)
>> >  {
>> > struct vpbe_config *cfg = vpbe_dev->cfg;
>> > int out_index = vpbe_dev->current_out_index;
>> > +   struct vpbe_output *output = &cfg->outputs[out_index];
>> > int sd_index = vpbe_dev->current_sd_index;
>> > -   int ret;
>> > +   int ret, i;
>> >
>> >
>> > if (!(cfg->outputs[out_index].output.capabilities &
>> > -   V4L2_OUT_CAP_PRESETS))
>> > +   V4L2_OUT_CAP_CUSTOM_TIMINGS))
>
> Can you make a follow-up patch that renames V4L2_IN/OUT_CAP_CUSTOM_TIMINGS to
> V4L2_IN/OUT_CAP_DV_TIMINGS? The old name for this define is deprecated, so it
> would be nice to fix this in this driver as well.
>
> The code that adds the new define names went in just two days ago, so as far
> as I am concerned there is no need to modify the patch again. A follow-up
> patch is sufficient.
>
Ok, I'll create a follow up patch.

Regards,
--Prabhakar

> Regards,
>
> Hans
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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] dm644x: replace the obsolete preset API by the timings API.

2012-09-28 Thread Hans Verkuil
Hi Prabhakar!

On Fri September 28 2012 14:44:59 Prabhakar Lad wrote:
> Hi Kevin,
> 
> On Wed, Aug 8, 2012 at 6:00 PM, Prabhakar Lad  wrote:
> > From: Hans Verkuil 
> >
> > Signed-off-by: Hans Verkuil 
> > Signed-off-by: Lad, Prabhakar 
> > Signed-off-by: Manjunath Hadli 
> > ---
> >  arch/arm/mach-davinci/board-dm644x-evm.c   |   15 ++--
> >  arch/arm/mach-davinci/dm644x.c |   17 +---
> >  drivers/media/video/davinci/vpbe.c |  110 
> > 
> >  drivers/media/video/davinci/vpbe_display.c |   60 +++
> >  drivers/media/video/davinci/vpbe_venc.c|   25 +++---
> >  include/media/davinci/vpbe.h   |   14 ++--
> >  include/media/davinci/vpbe_types.h |8 +--
> >  include/media/davinci/vpbe_venc.h  |2 +-
> >  8 files changed, 111 insertions(+), 140 deletions(-)
> >
> Can you ACK this patch? Since this patch needs to go from Mauro's tree
> due to changes in media drivers folder structure.
> 
> Regards,
> --Prabhakar Lad
> 

...

> > -static int vpbe_s_dv_preset(struct vpbe_device *vpbe_dev,
> > -struct v4l2_dv_preset *dv_preset)
> > +static int vpbe_s_dv_timings(struct vpbe_device *vpbe_dev,
> > +struct v4l2_dv_timings *dv_timings)
> >  {
> > struct vpbe_config *cfg = vpbe_dev->cfg;
> > int out_index = vpbe_dev->current_out_index;
> > +   struct vpbe_output *output = &cfg->outputs[out_index];
> > int sd_index = vpbe_dev->current_sd_index;
> > -   int ret;
> > +   int ret, i;
> >
> >
> > if (!(cfg->outputs[out_index].output.capabilities &
> > -   V4L2_OUT_CAP_PRESETS))
> > +   V4L2_OUT_CAP_CUSTOM_TIMINGS))

Can you make a follow-up patch that renames V4L2_IN/OUT_CAP_CUSTOM_TIMINGS to
V4L2_IN/OUT_CAP_DV_TIMINGS? The old name for this define is deprecated, so it
would be nice to fix this in this driver as well.

The code that adds the new define names went in just two days ago, so as far
as I am concerned there is no need to modify the patch again. A follow-up
patch is sufficient.

Regards,

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


[PATCH 5/7] media: mx2_camera: fix const cropping related warnings

2012-09-28 Thread Guennadi Liakhovetski
A recent commit "[media] v4l2: make vidioc_s_crop const" introduced
warnings in mx2_camera. Fix them by cleanly separating writable and
read-only variables in cropping operations.

Signed-off-by: Guennadi Liakhovetski 
---
 drivers/media/platform/soc_camera/mx2_camera.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/soc_camera/mx2_camera.c 
b/drivers/media/platform/soc_camera/mx2_camera.c
index 29758b0..0854f83 100644
--- a/drivers/media/platform/soc_camera/mx2_camera.c
+++ b/drivers/media/platform/soc_camera/mx2_camera.c
@@ -1104,9 +1104,10 @@ static int mx2_camera_set_bus_param(struct 
soc_camera_device *icd)
 }
 
 static int mx2_camera_set_crop(struct soc_camera_device *icd,
-   struct v4l2_crop *a)
+   const struct v4l2_crop *a)
 {
-   struct v4l2_rect *rect = &a->c;
+   struct v4l2_crop a_writable = *a;
+   struct v4l2_rect *rect = &a_writable.c;
struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
struct v4l2_mbus_framefmt mf;
int ret;
-- 
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 1/7] media: sh_mobile_ceu_camera: fix const cropping related warnings

2012-09-28 Thread Guennadi Liakhovetski
A recent commit "[media] v4l2: make vidioc_s_crop const" introduced
warnings in sh_mobile_ceu_camera. Fix them by cleanly separating writable
and read-only variables in cropping operations.

Signed-off-by: Guennadi Liakhovetski 
---
 .../platform/soc_camera/sh_mobile_ceu_camera.c |   13 +++--
 1 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c 
b/drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c
index 78bcf23..4642e0d 100644
--- a/drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c
+++ b/drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c
@@ -1213,13 +1213,13 @@ static void sh_mobile_ceu_put_formats(struct 
soc_camera_device *icd)
 }
 
 /* Check if any dimension of r1 is smaller than respective one of r2 */
-static bool is_smaller(struct v4l2_rect *r1, struct v4l2_rect *r2)
+static bool is_smaller(const struct v4l2_rect *r1, const struct v4l2_rect *r2)
 {
return r1->width < r2->width || r1->height < r2->height;
 }
 
 /* Check if r1 fails to cover r2 */
-static bool is_inside(struct v4l2_rect *r1, struct v4l2_rect *r2)
+static bool is_inside(const struct v4l2_rect *r1, const struct v4l2_rect *r2)
 {
return r1->left > r2->left || r1->top > r2->top ||
r1->left + r1->width < r2->left + r2->width ||
@@ -1294,7 +1294,7 @@ static void update_subrect(struct sh_mobile_ceu_cam *cam)
  * 3. if (2) failed, try to request the maximum image
  */
 static int client_s_crop(struct soc_camera_device *icd, struct v4l2_crop *crop,
-const struct v4l2_crop *cam_crop)
+struct v4l2_crop *cam_crop)
 {
struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
struct v4l2_rect *rect = &crop->c, *cam_rect = &cam_crop->c;
@@ -1550,7 +1550,8 @@ static int client_scale(struct soc_camera_device *icd,
 static int sh_mobile_ceu_set_crop(struct soc_camera_device *icd,
  const struct v4l2_crop *a)
 {
-   struct v4l2_rect *rect = &a->c;
+   struct v4l2_crop a_writable = *a;
+   const struct v4l2_rect *rect = &a_writable.c;
struct device *dev = icd->parent;
struct soc_camera_host *ici = to_soc_camera_host(dev);
struct sh_mobile_ceu_dev *pcdev = ici->priv;
@@ -1576,7 +1577,7 @@ static int sh_mobile_ceu_set_crop(struct 
soc_camera_device *icd,
 * 1. - 2. Apply iterative camera S_CROP for new input window, read back
 * actual camera rectangle.
 */
-   ret = client_s_crop(icd, a, &cam_crop);
+   ret = client_s_crop(icd, &a_writable, &cam_crop);
if (ret < 0)
return ret;
 
@@ -1977,7 +1978,7 @@ static int sh_mobile_ceu_try_fmt(struct soc_camera_device 
*icd,
 }
 
 static int sh_mobile_ceu_set_livecrop(struct soc_camera_device *icd,
- struct v4l2_crop *a)
+ const struct v4l2_crop *a)
 {
struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
struct soc_camera_host *ici = to_soc_camera_host(icd->parent);
-- 
1.7.2.5

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


[PATCH 6/7] media: mx1_camera: use the default .set_crop() implementation

2012-09-28 Thread Guennadi Liakhovetski
.set_crop() implementation in mx1_camera is identical with the default.
Remove the copy to switch to using the default stab.

Signed-off-by: Guennadi Liakhovetski 
---
 drivers/media/platform/soc_camera/mx1_camera.c |9 -
 1 files changed, 0 insertions(+), 9 deletions(-)

diff --git a/drivers/media/platform/soc_camera/mx1_camera.c 
b/drivers/media/platform/soc_camera/mx1_camera.c
index 560a65a..bbd18e6 100644
--- a/drivers/media/platform/soc_camera/mx1_camera.c
+++ b/drivers/media/platform/soc_camera/mx1_camera.c
@@ -470,14 +470,6 @@ static void mx1_camera_remove_device(struct 
soc_camera_device *icd)
pcdev->icd = NULL;
 }
 
-static int mx1_camera_set_crop(struct soc_camera_device *icd,
-  struct v4l2_crop *a)
-{
-   struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
-
-   return v4l2_subdev_call(sd, video, s_crop, a);
-}
-
 static int mx1_camera_set_bus_param(struct soc_camera_device *icd)
 {
struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
@@ -689,7 +681,6 @@ static struct soc_camera_host_ops mx1_soc_camera_host_ops = 
{
.add= mx1_camera_add_device,
.remove = mx1_camera_remove_device,
.set_bus_param  = mx1_camera_set_bus_param,
-   .set_crop   = mx1_camera_set_crop,
.set_fmt= mx1_camera_set_fmt,
.try_fmt= mx1_camera_try_fmt,
.init_videobuf  = mx1_camera_init_videobuf,
-- 
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 0/7] soc-camera and sh_vou cropping constification fixes

2012-09-28 Thread Guennadi Liakhovetski
These patches fix warnings, added by the recent commit

commit 4f996594ceaf6c3f9bc42b40c40b0f7f87b79c86
Author: Hans Verkuil 
Date:   Wed Sep 5 05:10:48 2012 -0300

[media] v4l2: make vidioc_s_crop const

If there are no objections, I'll include them in my (hopefully) last
3.7-merge pull request.

Thanks
Guennadi

Guennadi Liakhovetski (7):
  media: sh_mobile_ceu_camera: fix const cropping related warnings
  media: pxa_camera: fix const cropping related warnings
  media: sh_vou: fix const cropping related warnings
  media: mx3_camera: fix const cropping related warnings
  media: mx2_camera: fix const cropping related warnings
  media: mx1_camera: use the default .set_crop() implementation
  media: omap1_camera: fix const cropping related warnings

 drivers/media/platform/sh_vou.c|3 ++-
 drivers/media/platform/soc_camera/mx1_camera.c |9 -
 drivers/media/platform/soc_camera/mx2_camera.c |5 +++--
 drivers/media/platform/soc_camera/mx3_camera.c |5 +++--
 drivers/media/platform/soc_camera/omap1_camera.c   |4 ++--
 drivers/media/platform/soc_camera/pxa_camera.c |4 ++--
 .../platform/soc_camera/sh_mobile_ceu_camera.c |   13 +++--
 7 files changed, 19 insertions(+), 24 deletions(-)

-- 
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 7/7] media: omap1_camera: fix const cropping related warnings

2012-09-28 Thread Guennadi Liakhovetski
A recent commit "[media] v4l2: make vidioc_s_crop const" introduced
warnings in omap1_camera. Fix them by adjusting a function declaration.

Signed-off-by: Guennadi Liakhovetski 
---
 drivers/media/platform/soc_camera/omap1_camera.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/soc_camera/omap1_camera.c 
b/drivers/media/platform/soc_camera/omap1_camera.c
index fa08c76..13636a5 100644
--- a/drivers/media/platform/soc_camera/omap1_camera.c
+++ b/drivers/media/platform/soc_camera/omap1_camera.c
@@ -1215,9 +1215,9 @@ static int set_mbus_format(struct omap1_cam_dev *pcdev, 
struct device *dev,
 }
 
 static int omap1_cam_set_crop(struct soc_camera_device *icd,
-  struct v4l2_crop *crop)
+  const struct v4l2_crop *crop)
 {
-   struct v4l2_rect *rect = &crop->c;
+   const struct v4l2_rect *rect = &crop->c;
const struct soc_camera_format_xlate *xlate = icd->current_fmt;
struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
struct device *dev = icd->parent;
-- 
1.7.2.5

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


[PATCH 3/7] media: sh_vou: fix const cropping related warnings

2012-09-28 Thread Guennadi Liakhovetski
A recent commit "[media] v4l2: make vidioc_s_crop const" introduced
warnings in sh_vou. Fix them by cleanly separating writable and
read-only variables in cropping operations.

Signed-off-by: Guennadi Liakhovetski 
---
 drivers/media/platform/sh_vou.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/media/platform/sh_vou.c b/drivers/media/platform/sh_vou.c
index 85fd312..a1c87f0 100644
--- a/drivers/media/platform/sh_vou.c
+++ b/drivers/media/platform/sh_vou.c
@@ -935,9 +935,10 @@ static int sh_vou_g_crop(struct file *file, void *fh, 
struct v4l2_crop *a)
 /* Assume a dull encoder, do all the work ourselves. */
 static int sh_vou_s_crop(struct file *file, void *fh, const struct v4l2_crop 
*a)
 {
+   struct v4l2_crop a_writable = *a;
struct video_device *vdev = video_devdata(file);
struct sh_vou_device *vou_dev = video_get_drvdata(vdev);
-   struct v4l2_rect *rect = &a->c;
+   struct v4l2_rect *rect = &a_writable.c;
struct v4l2_crop sd_crop = {.type = V4L2_BUF_TYPE_VIDEO_OUTPUT};
struct v4l2_pix_format *pix = &vou_dev->pix;
struct sh_vou_geometry geo;
-- 
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 4/7] media: mx3_camera: fix const cropping related warnings

2012-09-28 Thread Guennadi Liakhovetski
A recent commit "[media] v4l2: make vidioc_s_crop const" introduced
warnings in mx3_camera. Fix them by cleanly separating writable and
read-only variables in cropping operations.

Signed-off-by: Guennadi Liakhovetski 
---
 drivers/media/platform/soc_camera/mx3_camera.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/soc_camera/mx3_camera.c 
b/drivers/media/platform/soc_camera/mx3_camera.c
index 16975c6..968b6d7 100644
--- a/drivers/media/platform/soc_camera/mx3_camera.c
+++ b/drivers/media/platform/soc_camera/mx3_camera.c
@@ -799,9 +799,10 @@ static inline void stride_align(__u32 *width)
  * default g_crop and cropcap from soc_camera.c
  */
 static int mx3_camera_set_crop(struct soc_camera_device *icd,
-  struct v4l2_crop *a)
+  const struct v4l2_crop *a)
 {
-   struct v4l2_rect *rect = &a->c;
+   struct v4l2_crop a_writable = *a;
+   struct v4l2_rect *rect = &a_writable.c;
struct soc_camera_host *ici = to_soc_camera_host(icd->parent);
struct mx3_camera_dev *mx3_cam = ici->priv;
struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
-- 
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 2/7] media: pxa_camera: fix const cropping related warnings

2012-09-28 Thread Guennadi Liakhovetski
A recent commit "[media] v4l2: make vidioc_s_crop const" introduced
warnings in pxa_camera.c. Fix them by adjusting a function declaration.

Signed-off-by: Guennadi Liakhovetski 
---
 drivers/media/platform/soc_camera/pxa_camera.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/soc_camera/pxa_camera.c 
b/drivers/media/platform/soc_camera/pxa_camera.c
index 9c21e01..329b477 100644
--- a/drivers/media/platform/soc_camera/pxa_camera.c
+++ b/drivers/media/platform/soc_camera/pxa_camera.c
@@ -1337,9 +1337,9 @@ static int pxa_camera_check_frame(u32 width, u32 height)
 }
 
 static int pxa_camera_set_crop(struct soc_camera_device *icd,
-  struct v4l2_crop *a)
+  const struct v4l2_crop *a)
 {
-   struct v4l2_rect *rect = &a->c;
+   const struct v4l2_rect *rect = &a->c;
struct device *dev = icd->parent;
struct soc_camera_host *ici = to_soc_camera_host(dev);
struct pxa_camera_dev *pcdev = ici->priv;
-- 
1.7.2.5

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


Re: [PATCH 1/2] dm644x: replace the obsolete preset API by the timings API.

2012-09-28 Thread Prabhakar Lad
Hi Kevin,

On Wed, Aug 8, 2012 at 6:00 PM, Prabhakar Lad  wrote:
> From: Hans Verkuil 
>
> Signed-off-by: Hans Verkuil 
> Signed-off-by: Lad, Prabhakar 
> Signed-off-by: Manjunath Hadli 
> ---
>  arch/arm/mach-davinci/board-dm644x-evm.c   |   15 ++--
>  arch/arm/mach-davinci/dm644x.c |   17 +---
>  drivers/media/video/davinci/vpbe.c |  110 
> 
>  drivers/media/video/davinci/vpbe_display.c |   60 +++
>  drivers/media/video/davinci/vpbe_venc.c|   25 +++---
>  include/media/davinci/vpbe.h   |   14 ++--
>  include/media/davinci/vpbe_types.h |8 +--
>  include/media/davinci/vpbe_venc.h  |2 +-
>  8 files changed, 111 insertions(+), 140 deletions(-)
>
Can you ACK this patch? Since this patch needs to go from Mauro's tree
due to changes in media drivers folder structure.

Regards,
--Prabhakar Lad

> diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c 
> b/arch/arm/mach-davinci/board-dm644x-evm.c
> index d34ed55..3baf56d 100644
> --- a/arch/arm/mach-davinci/board-dm644x-evm.c
> +++ b/arch/arm/mach-davinci/board-dm644x-evm.c
> @@ -23,6 +23,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>
>  #include 
> @@ -620,7 +621,7 @@ static struct vpbe_enc_mode_info 
> dm644xevm_enc_std_timing[] = {
> {
> .name   = "ntsc",
> .timings_type   = VPBE_ENC_STD,
> -   .timings= {V4L2_STD_525_60},
> +   .std_id = V4L2_STD_525_60,
> .interlaced = 1,
> .xres   = 720,
> .yres   = 480,
> @@ -632,7 +633,7 @@ static struct vpbe_enc_mode_info 
> dm644xevm_enc_std_timing[] = {
> {
> .name   = "pal",
> .timings_type   = VPBE_ENC_STD,
> -   .timings= {V4L2_STD_625_50},
> +   .std_id = V4L2_STD_625_50,
> .interlaced = 1,
> .xres   = 720,
> .yres   = 576,
> @@ -647,8 +648,8 @@ static struct vpbe_enc_mode_info 
> dm644xevm_enc_std_timing[] = {
>  static struct vpbe_enc_mode_info dm644xevm_enc_preset_timing[] = {
> {
> .name   = "480p59_94",
> -   .timings_type   = VPBE_ENC_DV_PRESET,
> -   .timings= {V4L2_DV_480P59_94},
> +   .timings_type   = VPBE_ENC_CUSTOM_TIMINGS,
> +   .dv_timings = V4L2_DV_BT_CEA_720X480P59_94,
> .interlaced = 0,
> .xres   = 720,
> .yres   = 480,
> @@ -659,8 +660,8 @@ static struct vpbe_enc_mode_info 
> dm644xevm_enc_preset_timing[] = {
> },
> {
> .name   = "576p50",
> -   .timings_type   = VPBE_ENC_DV_PRESET,
> -   .timings= {V4L2_DV_576P50},
> +   .timings_type   = VPBE_ENC_CUSTOM_TIMINGS,
> +   .dv_timings = V4L2_DV_BT_CEA_720X576P50,
> .interlaced = 0,
> .xres   = 720,
> .yres   = 576,
> @@ -698,7 +699,7 @@ static struct vpbe_output dm644xevm_vpbe_outputs[] = {
> .index  = 1,
> .name   = "Component",
> .type   = V4L2_OUTPUT_TYPE_ANALOG,
> -   .capabilities   = V4L2_OUT_CAP_PRESETS,
> +   .capabilities   = V4L2_OUT_CAP_CUSTOM_TIMINGS,
> },
> .subdev_name= VPBE_VENC_SUBDEV_NAME,
> .default_mode   = "480p59_94",
> diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
> index c8b8666..79d2880 100644
> --- a/arch/arm/mach-davinci/dm644x.c
> +++ b/arch/arm/mach-davinci/dm644x.c
> @@ -701,7 +701,7 @@ static struct resource dm644x_venc_resources[] = {
>  #define DM644X_VPSS_DACCLKEN  BIT(4)
>
>  static int dm644x_venc_setup_clock(enum vpbe_enc_timings_type type,
> -  unsigned int mode)
> +  unsigned int pclock)
>  {
> int ret = 0;
> u32 v = DM644X_VPSS_VENCLKEN;
> @@ -711,27 +711,18 @@ static int dm644x_venc_setup_clock(enum 
> vpbe_enc_timings_type type,
> v |= DM644X_VPSS_DACCLKEN;
> writel(v, DAVINCI_SYSMOD_VIRT(SYSMOD_VPSS_CLKCTL));
> break;
> -   case VPBE_ENC_DV_PRESET:
> -   switch (mode) {
> -   case V4L2_DV_480P59_94:
> -   case V4L2_DV_576P50:
> +   case VPBE_ENC_CUSTOM_TIMINGS:
> +   if (pclock <= 2700) {
> v |= DM644X_VPSS_MUXSEL_PLL2_MODE |
>  DM644X_VPSS_DACCLKEN;
> writel(v, DAVINCI_SYSMOD_VIRT(SYSMOD_VPSS_CLKCTL));
> -   break;
> -   case V4L2_DV_720P

Re: [git:v4l-dvb/for_v3.7] [media] add LNA support for DVB API

2012-09-28 Thread Hans Verkuil
Hi Antti,

Mauro asked me to look into LNA as well, in particular how this could be done
on the analog side as well.

While reading through this patch I noticed that the new property was added to
dtv_property_process_set, but not to dtv_property_process_get. Can you look
into that and add 'get' support for this property?

Thanks!

Hans

On Thu September 27 2012 19:28:09 Mauro Carvalho Chehab wrote:
> This is an automatic generated email to let you know that the following patch 
> were queued at the 
> http://git.linuxtv.org/media_tree.git tree:
> 
> Subject: [media] add LNA support for DVB API
> Author:  Antti Palosaari 
> Date:Wed Jul 11 21:54:50 2012 -0300
> 
> Signed-off-by: Antti Palosaari 
> Signed-off-by: Mauro Carvalho Chehab 
> 
>  drivers/media/dvb-core/dvb_frontend.c |5 +
>  drivers/media/dvb-core/dvb_frontend.h |1 +
>  include/linux/dvb/frontend.h  |4 +++-
>  3 files changed, 9 insertions(+), 1 deletions(-)
> 
> ---
> 
> http://git.linuxtv.org/media_tree.git?a=commitdiff;h=8a2697abc1f0388d44b78ac109d9f03ec75c2683
> 
> diff --git a/drivers/media/dvb-core/dvb_frontend.c 
> b/drivers/media/dvb-core/dvb_frontend.c
> index 1f3b16d..8f58f24 100644
> --- a/drivers/media/dvb-core/dvb_frontend.c
> +++ b/drivers/media/dvb-core/dvb_frontend.c
> @@ -1022,6 +1022,7 @@ static struct dtv_cmds_h dtv_cmds[DTV_MAX_COMMAND + 1] 
> = {
>  
>   _DTV_CMD(DTV_STREAM_ID, 1, 0),
>   _DTV_CMD(DTV_DVBT2_PLP_ID_LEGACY, 1, 0),
> + _DTV_CMD(DTV_LNA, 1, 0),
>  
>   /* Get */
>   _DTV_CMD(DTV_DISEQC_SLAVE_REPLY, 0, 1),
> @@ -1730,6 +1731,10 @@ static int dtv_property_process_set(struct 
> dvb_frontend *fe,
>   case DTV_INTERLEAVING:
>   c->interleaving = tvp->u.data;
>   break;
> + case DTV_LNA:
> + if (fe->ops.set_lna)
> + r = fe->ops.set_lna(fe, tvp->u.data);
> + break;
>  
>   /* ISDB-T Support here */
>   case DTV_ISDBT_PARTIAL_RECEPTION:
> diff --git a/drivers/media/dvb-core/dvb_frontend.h 
> b/drivers/media/dvb-core/dvb_frontend.h
> index 33996a0..44a445c 100644
> --- a/drivers/media/dvb-core/dvb_frontend.h
> +++ b/drivers/media/dvb-core/dvb_frontend.h
> @@ -303,6 +303,7 @@ struct dvb_frontend_ops {
>   int (*dishnetwork_send_legacy_command)(struct dvb_frontend* fe, 
> unsigned long cmd);
>   int (*i2c_gate_ctrl)(struct dvb_frontend* fe, int enable);
>   int (*ts_bus_ctrl)(struct dvb_frontend* fe, int acquire);
> + int (*set_lna)(struct dvb_frontend *, int);
>  
>   /* These callbacks are for devices that implement their own
>* tuning algorithms, rather than a simple swzigzag
> diff --git a/include/linux/dvb/frontend.h b/include/linux/dvb/frontend.h
> index 57e2b17..c12d452 100644
> --- a/include/linux/dvb/frontend.h
> +++ b/include/linux/dvb/frontend.h
> @@ -363,8 +363,9 @@ struct dvb_frontend_event {
>  #define DTV_ATSCMH_SCCC_CODE_MODE_D  59
>  
>  #define DTV_INTERLEAVING 60
> +#define DTV_LNA  61
>  
> -#define DTV_MAX_COMMAND  DTV_INTERLEAVING
> +#define DTV_MAX_COMMAND  DTV_LNA
>  
>  typedef enum fe_pilot {
>   PILOT_ON,
> @@ -438,6 +439,7 @@ enum atscmh_rs_code_mode {
>  };
>  
>  #define NO_STREAM_ID_FILTER  (~0U)
> +#define LNA_AUTO(~0U)
>  
>  struct dtv_cmds_h {
>   char*name;  /* A display name for debugging purposes */
> 
> ___
> linuxtv-commits mailing list
> linuxtv-comm...@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linuxtv-commits
> 
--
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] mt9v022: support required register settings in snapshot mode

2012-09-28 Thread Guennadi Liakhovetski
Hi Anatolij

On Fri, 28 Sep 2012, Anatolij Gustschin wrote:

> Some camera systems cannot operate mt9v022 in normal mode and use
> only the snapshot mode. The TechNote for mt9v022 (TN0960) and mt9v024
> (TN-09-225) describes required register settings when configuring the
> snapshot operation. The snapshot mode requires that certain automatic
> functions of the image sensor should be disabled or set to fixed values.
> 
> According to the TechNote bit 2 and bit 9 in the register 0x20 must be
> set in snapshot mode and unset for normal operation. This applies for
> mt9v022 Rev.3 and mt9v024. Add required reg. 0x20 settings dependent on
> sensor chip version.
> 
> Signed-off-by: Anatolij Gustschin 

I'm afraid, I don't understand again

> ---
>  drivers/media/i2c/soc_camera/mt9v022.c |   31 ---
>  1 files changed, 28 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/media/i2c/soc_camera/mt9v022.c 
> b/drivers/media/i2c/soc_camera/mt9v022.c
> index 8feaddc..2abe999 100644
> --- a/drivers/media/i2c/soc_camera/mt9v022.c
> +++ b/drivers/media/i2c/soc_camera/mt9v022.c
> @@ -51,6 +51,7 @@ MODULE_PARM_DESC(sensor_type, "Sensor type: \"colour\" or 
> \"monochrome\"");
>  #define MT9V022_PIXEL_OPERATION_MODE 0x0f
>  #define MT9V022_LED_OUT_CONTROL  0x1b
>  #define MT9V022_ADC_MODE_CONTROL 0x1c
> +#define MT9V022_REG320x20
>  #define MT9V022_ANALOG_GAIN  0x35
>  #define MT9V022_BLACK_LEVEL_CALIB_CTRL   0x47
>  #define MT9V022_PIXCLK_FV_LV 0x74
> @@ -79,7 +80,8 @@ MODULE_PARM_DESC(sensor_type, "Sensor type: \"colour\" or 
> \"monochrome\"");
>  #define MT9V022_VERTICAL_BLANKING_MAX3000
>  #define MT9V022_VERTICAL_BLANKING_DEF45
>  
> -#define is_mt9v024(id) (id == 0x1324)
> +#define is_mt9v022_rev3(id)  (id == 0x1313)
> +#define is_mt9v024(id)   (id == 0x1324)
>  
>  /* MT9V022 has only one fixed colorspace per pixelcode */
>  struct mt9v022_datafmt {
> @@ -153,6 +155,7 @@ struct mt9v022 {
>   int num_fmts;
>   int model;  /* V4L2_IDENT_MT9V022* codes from v4l2-chip-ident.h */
>   u16 chip_control;
> + u16 chip_version;
>   unsigned short y_skip_top;  /* Lines to skip at the top */
>  };
>  
> @@ -235,12 +238,32 @@ static int mt9v022_s_stream(struct v4l2_subdev *sd, int 
> enable)
>   struct i2c_client *client = v4l2_get_subdevdata(sd);
>   struct mt9v022 *mt9v022 = to_mt9v022(client);
>  
> - if (enable)
> + if (enable) {
>   /* Switch to master "normal" mode */
>   mt9v022->chip_control &= ~0x10;
> - else
> + if (is_mt9v022_rev3(mt9v022->chip_version) ||
> + is_mt9v024(mt9v022->chip_version)) {
> + /*
> +  * Unset snapshot mode specific settings: clear bit 9
> +  * and bit 2 in reg. 0x20 when in normal mode.
> +  */
> + if (reg_clear(client, MT9V022_REG32, 0x204))
> + return -EIO;
> + }
> + } else {
>   /* Switch to snapshot mode */
>   mt9v022->chip_control |= 0x10;
> + if (is_mt9v022_rev3(mt9v022->chip_version) ||
> + is_mt9v024(mt9v022->chip_version)) {
> + /*
> +  * Required settings for snapshot mode: set bit 9
> +  * (RST enable) and bit 2 (CR enable) in reg. 0x20
> +  * See TechNote TN0960 or TN-09-225.
> +  */
> + if (reg_set(client, MT9V022_REG32, 0x204))
> + return -EIO;
> + }
> + }

Do I understand it right, that now on mt9v022 rev.3 and mt9v024 you 
unconditionally added using REG32 for leaving the snapshot mode on 
streamon and entering it on streamoff. This should be ok in principle, 
since that's also what we're trying to do, using the CHIP_CONTROL 
register. But in your comment you say, that on some _systems_ you can only 
_operate_ in snapshot mode. I.e. the snapshot mode enabled during running 
streaming, right? Then how does this patch help you with that?

Thanks
Guennadi

>  
>   if (reg_write(client, MT9V022_CHIP_CONTROL, mt9v022->chip_control) < 0)
>   return -EIO;
> @@ -652,6 +675,8 @@ static int mt9v022_video_probe(struct i2c_client *client)
>   goto ei2c;
>   }
>  
> + mt9v022->chip_version = data;
> +
>   mt9v022->reg = is_mt9v024(data) ? &mt9v024_register :
>   &mt9v022_register;
>  
> -- 
> 1.7.1
> 

---
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 v2 3/3] mt9v022: set y_skip_top field to zero as default

2012-09-28 Thread Guennadi Liakhovetski
Hi Eric

On Fri, 28 Sep 2012, Guennadi Liakhovetski wrote:

> Hi Anatolij
> 
> I can take this patch, but we need an ack from a PXA / ARM maintainer.

Could we have your ack, please?

Thanks
Guennadi

> On Fri, 28 Sep 2012, Anatolij Gustschin wrote:
> 
> > Set "y_skip_top" to zero and revise comment as I do not see this line
> > corruption on two different mt9v022 setups. The first read-out line
> > is perfectly fine. Add mt9v022 platform data configuring y_skip_top
> > for platforms that have issues with the first read-out line. Set
> > y_skip_top to 1 for pcm990 board.
> > 
> > Signed-off-by: Anatolij Gustschin 
> > ---
> > Changes since first version:
> >  - add platform data to mt9v022 with only one parameter to initialise 
> >y_skip_top, use 0 as default and set it to 1 on pcm990-baseboard.c
> >  - revise commit log
> >  - rebase on staging/for_v3.7 branch
> > 
> >  arch/arm/mach-pxa/pcm990-baseboard.c   |6 ++
> >  drivers/media/i2c/soc_camera/mt9v022.c |8 +---
> >  include/media/mt9v022.h|   16 
> >  3 files changed, 27 insertions(+), 3 deletions(-)
> >  create mode 100644 include/media/mt9v022.h
> > 
> > diff --git a/arch/arm/mach-pxa/pcm990-baseboard.c 
> > b/arch/arm/mach-pxa/pcm990-baseboard.c
> > index cb723e8..e2973f2 100644
> > --- a/arch/arm/mach-pxa/pcm990-baseboard.c
> > +++ b/arch/arm/mach-pxa/pcm990-baseboard.c
> > @@ -26,6 +26,7 @@
> >  #include 
> >  #include 
> >  
> > +#include 
> >  #include 
> >  
> >  #include 
> > @@ -468,6 +469,10 @@ static struct i2c_board_info __initdata 
> > pcm990_i2c_devices[] = {
> > },
> >  };
> >  
> > +static struct mt9v022_platform_data mt9v022_pdata = {
> > +   .y_skip_top = 1,
> > +};
> > +
> >  static struct i2c_board_info pcm990_camera_i2c[] = {
> > {
> > I2C_BOARD_INFO("mt9v022", 0x48),
> > @@ -480,6 +485,7 @@ static struct soc_camera_link iclink[] = {
> > {
> > .bus_id = 0, /* Must match with the camera ID */
> > .board_info = &pcm990_camera_i2c[0],
> > +   .priv   = &mt9v022_pdata,
> > .i2c_adapter_id = 0,
> > .query_bus_param= pcm990_camera_query_bus_param,
> > .set_bus_param  = pcm990_camera_set_bus_param,
> > diff --git a/drivers/media/i2c/soc_camera/mt9v022.c 
> > b/drivers/media/i2c/soc_camera/mt9v022.c
> > index e0f4cb4..8feaddc 100644
> > --- a/drivers/media/i2c/soc_camera/mt9v022.c
> > +++ b/drivers/media/i2c/soc_camera/mt9v022.c
> > @@ -15,6 +15,7 @@
> >  #include 
> >  #include 
> >  
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -849,6 +850,7 @@ static int mt9v022_probe(struct i2c_client *client,
> > struct mt9v022 *mt9v022;
> > struct soc_camera_link *icl = soc_camera_i2c_to_link(client);
> > struct i2c_adapter *adapter = to_i2c_adapter(client->dev.parent);
> > +   struct mt9v022_platform_data *pdata = icl->priv;
> > int ret;
> >  
> > if (!icl) {
> > @@ -912,10 +914,10 @@ static int mt9v022_probe(struct i2c_client *client,
> > mt9v022->chip_control = MT9V022_CHIP_CONTROL_DEFAULT;
> >  
> > /*
> > -* MT9V022 _really_ corrupts the first read out line.
> > -* TODO: verify on i.MX31
> > +* On some platforms the first read out line is corrupted.
> > +* Workaround it by skipping if indicated by platform data.
> >  */
> > -   mt9v022->y_skip_top = 1;
> > +   mt9v022->y_skip_top = pdata ? pdata->y_skip_top : 0;
> > mt9v022->rect.left  = MT9V022_COLUMN_SKIP;
> > mt9v022->rect.top   = MT9V022_ROW_SKIP;
> > mt9v022->rect.width = MT9V022_MAX_WIDTH;
> > diff --git a/include/media/mt9v022.h b/include/media/mt9v022.h
> > new file mode 100644
> > index 000..4056180
> > --- /dev/null
> > +++ b/include/media/mt9v022.h
> > @@ -0,0 +1,16 @@
> > +/*
> > + * mt9v022 sensor
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + */
> > +
> > +#ifndef __MT9V022_H__
> > +#define __MT9V022_H__
> > +
> > +struct mt9v022_platform_data {
> > +   unsigned short y_skip_top;  /* Lines to skip at the top */
> > +};
> > +
> > +#endif
> > -- 
> > 1.7.1
> > 
> 
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
> 

---
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 v2 3/3] mt9v022: set y_skip_top field to zero as default

2012-09-28 Thread Guennadi Liakhovetski
Hi Anatolij

I can take this patch, but we need an ack from a PXA / ARM maintainer.

Thanks
Guennadi

On Fri, 28 Sep 2012, Anatolij Gustschin wrote:

> Set "y_skip_top" to zero and revise comment as I do not see this line
> corruption on two different mt9v022 setups. The first read-out line
> is perfectly fine. Add mt9v022 platform data configuring y_skip_top
> for platforms that have issues with the first read-out line. Set
> y_skip_top to 1 for pcm990 board.
> 
> Signed-off-by: Anatolij Gustschin 
> ---
> Changes since first version:
>  - add platform data to mt9v022 with only one parameter to initialise 
>y_skip_top, use 0 as default and set it to 1 on pcm990-baseboard.c
>  - revise commit log
>  - rebase on staging/for_v3.7 branch
> 
>  arch/arm/mach-pxa/pcm990-baseboard.c   |6 ++
>  drivers/media/i2c/soc_camera/mt9v022.c |8 +---
>  include/media/mt9v022.h|   16 
>  3 files changed, 27 insertions(+), 3 deletions(-)
>  create mode 100644 include/media/mt9v022.h
> 
> diff --git a/arch/arm/mach-pxa/pcm990-baseboard.c 
> b/arch/arm/mach-pxa/pcm990-baseboard.c
> index cb723e8..e2973f2 100644
> --- a/arch/arm/mach-pxa/pcm990-baseboard.c
> +++ b/arch/arm/mach-pxa/pcm990-baseboard.c
> @@ -26,6 +26,7 @@
>  #include 
>  #include 
>  
> +#include 
>  #include 
>  
>  #include 
> @@ -468,6 +469,10 @@ static struct i2c_board_info __initdata 
> pcm990_i2c_devices[] = {
>   },
>  };
>  
> +static struct mt9v022_platform_data mt9v022_pdata = {
> + .y_skip_top = 1,
> +};
> +
>  static struct i2c_board_info pcm990_camera_i2c[] = {
>   {
>   I2C_BOARD_INFO("mt9v022", 0x48),
> @@ -480,6 +485,7 @@ static struct soc_camera_link iclink[] = {
>   {
>   .bus_id = 0, /* Must match with the camera ID */
>   .board_info = &pcm990_camera_i2c[0],
> + .priv   = &mt9v022_pdata,
>   .i2c_adapter_id = 0,
>   .query_bus_param= pcm990_camera_query_bus_param,
>   .set_bus_param  = pcm990_camera_set_bus_param,
> diff --git a/drivers/media/i2c/soc_camera/mt9v022.c 
> b/drivers/media/i2c/soc_camera/mt9v022.c
> index e0f4cb4..8feaddc 100644
> --- a/drivers/media/i2c/soc_camera/mt9v022.c
> +++ b/drivers/media/i2c/soc_camera/mt9v022.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -849,6 +850,7 @@ static int mt9v022_probe(struct i2c_client *client,
>   struct mt9v022 *mt9v022;
>   struct soc_camera_link *icl = soc_camera_i2c_to_link(client);
>   struct i2c_adapter *adapter = to_i2c_adapter(client->dev.parent);
> + struct mt9v022_platform_data *pdata = icl->priv;
>   int ret;
>  
>   if (!icl) {
> @@ -912,10 +914,10 @@ static int mt9v022_probe(struct i2c_client *client,
>   mt9v022->chip_control = MT9V022_CHIP_CONTROL_DEFAULT;
>  
>   /*
> -  * MT9V022 _really_ corrupts the first read out line.
> -  * TODO: verify on i.MX31
> +  * On some platforms the first read out line is corrupted.
> +  * Workaround it by skipping if indicated by platform data.
>*/
> - mt9v022->y_skip_top = 1;
> + mt9v022->y_skip_top = pdata ? pdata->y_skip_top : 0;
>   mt9v022->rect.left  = MT9V022_COLUMN_SKIP;
>   mt9v022->rect.top   = MT9V022_ROW_SKIP;
>   mt9v022->rect.width = MT9V022_MAX_WIDTH;
> diff --git a/include/media/mt9v022.h b/include/media/mt9v022.h
> new file mode 100644
> index 000..4056180
> --- /dev/null
> +++ b/include/media/mt9v022.h
> @@ -0,0 +1,16 @@
> +/*
> + * mt9v022 sensor
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#ifndef __MT9V022_H__
> +#define __MT9V022_H__
> +
> +struct mt9v022_platform_data {
> + unsigned short y_skip_top;  /* Lines to skip at the top */
> +};
> +
> +#endif
> -- 
> 1.7.1
> 

---
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: tda18271 driver power consumption

2012-09-28 Thread Mauro Carvalho Chehab
Em Thu, 27 Sep 2012 17:58:24 -0400
Michael Krufky  escreveu:

> On Thu, Sep 27, 2012 at 5:38 PM, Antti Palosaari  wrote:
> > On 09/28/2012 12:20 AM, Michael Krufky wrote:

> > Mike, There is other problem too. PCTV 520e, which is Em28xx + DRX-K +
> > TDA18271, fails to attach tuner now. Tuner is wired behind DRX-K I2C bus.
> > TDA18271 driver does very much I/O during attach and I2C error is raised
> > during attach now. Earlier it worked as DRX-K firmware was downloaded before
> > tuner was attached, but now both DRX-K fw download and tuner attach happens
> > same time leading that error.
> 
> Why is the DRX-K firmware downloading at the same time as tuner
> attach?  Shouldn't the demod attach be finished before the tuner
> attach begins?

Michael,

What happens is that udev changes forced drivers to load firmware 
asynchronously,
as, otherwise, udev won't load any firmware at all. Also, there's no warranty 
that
the firmware will be loaded on 2 seconds or so (Anti's hack were to add a 2 
seconds
wait after drxk atttach, to wait for firmware load).

What I suspect is that tda18271 init is being interruped in the middle, by the
drxk firmware load. If this is the case, the solution is clean and quick: just
use the new i2c_lock_adapter() way to lock the I2C bus to tda18271 during the
critical part of the code where the register init happens.


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


[PATCH v3 2/4] mcam-core: implement the control framework.

2012-09-28 Thread Javier Martin
Reviewed-by: Hans Verkuil 
Signed-off-by: Hans Verkuil 
Signed-off-by: Javier Martin 
---
 drivers/media/platform/marvell-ccic/mcam-core.c |   54 ---
 drivers/media/platform/marvell-ccic/mcam-core.h |2 +
 2 files changed, 11 insertions(+), 45 deletions(-)

diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c 
b/drivers/media/platform/marvell-ccic/mcam-core.c
index ce2b7b4..568f8a5 100644
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1232,47 +1233,6 @@ static int mcam_vidioc_dqbuf(struct file *filp, void 
*priv,
return ret;
 }
 
-
-
-static int mcam_vidioc_queryctrl(struct file *filp, void *priv,
-   struct v4l2_queryctrl *qc)
-{
-   struct mcam_camera *cam = priv;
-   int ret;
-
-   mutex_lock(&cam->s_mutex);
-   ret = sensor_call(cam, core, queryctrl, qc);
-   mutex_unlock(&cam->s_mutex);
-   return ret;
-}
-
-
-static int mcam_vidioc_g_ctrl(struct file *filp, void *priv,
-   struct v4l2_control *ctrl)
-{
-   struct mcam_camera *cam = priv;
-   int ret;
-
-   mutex_lock(&cam->s_mutex);
-   ret = sensor_call(cam, core, g_ctrl, ctrl);
-   mutex_unlock(&cam->s_mutex);
-   return ret;
-}
-
-
-static int mcam_vidioc_s_ctrl(struct file *filp, void *priv,
-   struct v4l2_control *ctrl)
-{
-   struct mcam_camera *cam = priv;
-   int ret;
-
-   mutex_lock(&cam->s_mutex);
-   ret = sensor_call(cam, core, s_ctrl, ctrl);
-   mutex_unlock(&cam->s_mutex);
-   return ret;
-}
-
-
 static int mcam_vidioc_querycap(struct file *file, void *priv,
struct v4l2_capability *cap)
 {
@@ -1520,9 +1480,6 @@ static const struct v4l2_ioctl_ops mcam_v4l_ioctl_ops = {
.vidioc_dqbuf   = mcam_vidioc_dqbuf,
.vidioc_streamon= mcam_vidioc_streamon,
.vidioc_streamoff   = mcam_vidioc_streamoff,
-   .vidioc_queryctrl   = mcam_vidioc_queryctrl,
-   .vidioc_g_ctrl  = mcam_vidioc_g_ctrl,
-   .vidioc_s_ctrl  = mcam_vidioc_s_ctrl,
.vidioc_g_parm  = mcam_vidioc_g_parm,
.vidioc_s_parm  = mcam_vidioc_s_parm,
.vidioc_enum_framesizes = mcam_vidioc_enum_framesizes,
@@ -1786,14 +1743,19 @@ int mccic_register(struct mcam_camera *cam)
/*
 * Get the v4l2 setup done.
 */
+   ret = v4l2_ctrl_handler_init(&cam->ctrl_handler, 10);
+   if (ret)
+   goto out_unregister;
+   cam->v4l2_dev.ctrl_handler = &cam->ctrl_handler;
+
mutex_lock(&cam->s_mutex);
cam->vdev = mcam_v4l_template;
cam->vdev.debug = 0;
cam->vdev.v4l2_dev = &cam->v4l2_dev;
+   video_set_drvdata(&cam->vdev, cam);
ret = video_register_device(&cam->vdev, VFL_TYPE_GRABBER, -1);
if (ret)
goto out;
-   video_set_drvdata(&cam->vdev, cam);
 
/*
 * If so requested, try to get our DMA buffers now.
@@ -1805,6 +1767,7 @@ int mccic_register(struct mcam_camera *cam)
}
 
 out:
+   v4l2_ctrl_handler_free(&cam->ctrl_handler);
mutex_unlock(&cam->s_mutex);
return ret;
 out_unregister:
@@ -1829,6 +1792,7 @@ void mccic_shutdown(struct mcam_camera *cam)
if (cam->buffer_mode == B_vmalloc)
mcam_free_dma_bufs(cam);
video_unregister_device(&cam->vdev);
+   v4l2_ctrl_handler_free(&cam->ctrl_handler);
v4l2_device_unregister(&cam->v4l2_dev);
 }
 
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.h 
b/drivers/media/platform/marvell-ccic/mcam-core.h
index bd6acba..f7c34ab 100644
--- a/drivers/media/platform/marvell-ccic/mcam-core.h
+++ b/drivers/media/platform/marvell-ccic/mcam-core.h
@@ -8,6 +8,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -104,6 +105,7 @@ struct mcam_camera {
 * should not be touched by the platform code.
 */
struct v4l2_device v4l2_dev;
+   struct v4l2_ctrl_handler ctrl_handler;
enum mcam_state state;
unsigned long flags;/* Buffer status, mainly (dev_lock) */
int users;  /* How many open FDs */
-- 
1.7.9.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 v3 3/4] via-camera: implement the control framework.

2012-09-28 Thread Javier Martin
And added a missing kfree to clean up the via_camera struct.

Reviewed-by: Hans Verkuil 
Signed-off-by: Hans Verkuil 
Signed-off-by: Javier Martin 
---
 drivers/media/platform/via-camera.c |   60 ---
 1 file changed, 14 insertions(+), 46 deletions(-)

diff --git a/drivers/media/platform/via-camera.c 
b/drivers/media/platform/via-camera.c
index eb404c2..1b5f97d 100644
--- a/drivers/media/platform/via-camera.c
+++ b/drivers/media/platform/via-camera.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -63,6 +64,7 @@ enum viacam_opstate { S_IDLE = 0, S_RUNNING = 1 };
 
 struct via_camera {
struct v4l2_device v4l2_dev;
+   struct v4l2_ctrl_handler ctrl_handler;
struct video_device vdev;
struct v4l2_subdev *sensor;
struct platform_device *platdev;
@@ -818,47 +820,6 @@ static int viacam_g_chip_ident(struct file *file, void 
*priv,
 }
 
 /*
- * Control ops are passed through to the sensor.
- */
-static int viacam_queryctrl(struct file *filp, void *priv,
-   struct v4l2_queryctrl *qc)
-{
-   struct via_camera *cam = priv;
-   int ret;
-
-   mutex_lock(&cam->lock);
-   ret = sensor_call(cam, core, queryctrl, qc);
-   mutex_unlock(&cam->lock);
-   return ret;
-}
-
-
-static int viacam_g_ctrl(struct file *filp, void *priv,
-   struct v4l2_control *ctrl)
-{
-   struct via_camera *cam = priv;
-   int ret;
-
-   mutex_lock(&cam->lock);
-   ret = sensor_call(cam, core, g_ctrl, ctrl);
-   mutex_unlock(&cam->lock);
-   return ret;
-}
-
-
-static int viacam_s_ctrl(struct file *filp, void *priv,
-   struct v4l2_control *ctrl)
-{
-   struct via_camera *cam = priv;
-   int ret;
-
-   mutex_lock(&cam->lock);
-   ret = sensor_call(cam, core, s_ctrl, ctrl);
-   mutex_unlock(&cam->lock);
-   return ret;
-}
-
-/*
  * Only one input.
  */
 static int viacam_enum_input(struct file *filp, void *priv,
@@ -1214,9 +1175,6 @@ static int viacam_enum_frameintervals(struct file *filp, 
void *priv,
 
 static const struct v4l2_ioctl_ops viacam_ioctl_ops = {
.vidioc_g_chip_ident= viacam_g_chip_ident,
-   .vidioc_queryctrl   = viacam_queryctrl,
-   .vidioc_g_ctrl  = viacam_g_ctrl,
-   .vidioc_s_ctrl  = viacam_s_ctrl,
.vidioc_enum_input  = viacam_enum_input,
.vidioc_g_input = viacam_g_input,
.vidioc_s_input = viacam_s_input,
@@ -1418,8 +1376,12 @@ static __devinit int viacam_probe(struct platform_device 
*pdev)
ret = v4l2_device_register(&pdev->dev, &cam->v4l2_dev);
if (ret) {
dev_err(&pdev->dev, "Unable to register v4l2 device\n");
-   return ret;
+   goto out_free;
}
+   ret = v4l2_ctrl_handler_init(&cam->ctrl_handler, 10);
+   if (ret)
+   goto out_unregister;
+   cam->v4l2_dev.ctrl_handler = &cam->ctrl_handler;
/*
 * Convince the system that we can do DMA.
 */
@@ -1436,7 +1398,7 @@ static __devinit int viacam_probe(struct platform_device 
*pdev)
 */
ret = via_sensor_power_setup(cam);
if (ret)
-   goto out_unregister;
+   goto out_ctrl_hdl_free;
via_sensor_power_up(cam);
 
/*
@@ -1485,8 +1447,12 @@ out_irq:
free_irq(viadev->pdev->irq, cam);
 out_power_down:
via_sensor_power_release(cam);
+out_ctrl_hdl_free:
+   v4l2_ctrl_handler_free(&cam->ctrl_handler);
 out_unregister:
v4l2_device_unregister(&cam->v4l2_dev);
+out_free:
+   kfree(cam);
return ret;
 }
 
@@ -1499,6 +1465,8 @@ static __devexit int viacam_remove(struct platform_device 
*pdev)
v4l2_device_unregister(&cam->v4l2_dev);
free_irq(viadev->pdev->irq, cam);
via_sensor_power_release(cam);
+   v4l2_ctrl_handler_free(&cam->ctrl_handler);
+   kfree(cam);
via_cam_info = NULL;
return 0;
 }
-- 
1.7.9.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 v3 4/4] ov7670: remove legacy ctrl callbacks.

2012-09-28 Thread Javier Martin
via-camera and mcam-core were the only bridge drivers that used ov7670.
Since now they have been moved to use the ctrl framework, the old
legacy callbacks in the ov7670 can be removed.

Reviewed-by: Hans Verkuil 
Signed-off-by: Javier Martin 
---
 drivers/media/i2c/ov7670.c |7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index 2f6470a..361b101 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -1504,13 +1504,6 @@ static int ov7670_s_register(struct v4l2_subdev *sd, 
struct v4l2_dbg_register *r
 
 static const struct v4l2_subdev_core_ops ov7670_core_ops = {
.g_chip_ident = ov7670_g_chip_ident,
-   .g_ext_ctrls = v4l2_subdev_g_ext_ctrls,
-   .try_ext_ctrls = v4l2_subdev_try_ext_ctrls,
-   .s_ext_ctrls = v4l2_subdev_s_ext_ctrls,
-   .g_ctrl = v4l2_subdev_g_ctrl,
-   .s_ctrl = v4l2_subdev_s_ctrl,
-   .queryctrl = v4l2_subdev_queryctrl,
-   .querymenu = v4l2_subdev_querymenu,
.reset = ov7670_reset,
.init = ov7670_init,
 #ifdef CONFIG_VIDEO_ADV_DEBUG
-- 
1.7.9.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 v3 1/4] ov7670: use the control framework

2012-09-28 Thread Javier Martin
Reviewed-by: Hans Verkuil 
Signed-off-by: Javier Martin 
---
Changes since v2:
 - Do not use 'cur.val' to get gain value.

---
 drivers/media/i2c/ov7670.c |  310 
 1 file changed, 112 insertions(+), 198 deletions(-)

diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index 9d7a92e..2f6470a 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -222,9 +223,23 @@ struct ov7670_devtype {
 struct ov7670_format_struct;  /* coming later */
 struct ov7670_info {
struct v4l2_subdev sd;
+   struct v4l2_ctrl_handler hdl;
+   struct {
+   /* gain cluster */
+   struct v4l2_ctrl *auto_gain;
+   struct v4l2_ctrl *gain;
+   };
+   struct {
+   /* exposure cluster */
+   struct v4l2_ctrl *auto_exposure;
+   struct v4l2_ctrl *exposure;
+   };
+   struct {
+   /* saturation/hue cluster */
+   struct v4l2_ctrl *saturation;
+   struct v4l2_ctrl *hue;
+   };
struct ov7670_format_struct *fmt;  /* Current format */
-   unsigned char sat;  /* Saturation value */
-   int hue;/* Hue value */
int min_width;  /* Filter out smaller sizes */
int min_height; /* Filter out smaller sizes */
int clock_speed;/* External clock speed (MHz) */
@@ -240,6 +255,11 @@ static inline struct ov7670_info *to_state(struct 
v4l2_subdev *sd)
return container_of(sd, struct ov7670_info, sd);
 }
 
+static inline struct v4l2_subdev *to_sd(struct v4l2_ctrl *ctrl)
+{
+   return &container_of(ctrl->handler, struct ov7670_info, hdl)->sd;
+}
+
 
 
 /*
@@ -1195,23 +1215,23 @@ static int ov7670_cosine(int theta)
 
 
 static void ov7670_calc_cmatrix(struct ov7670_info *info,
-   int matrix[CMATRIX_LEN])
+   int matrix[CMATRIX_LEN], int sat, int hue)
 {
int i;
/*
 * Apply the current saturation setting first.
 */
for (i = 0; i < CMATRIX_LEN; i++)
-   matrix[i] = (info->fmt->cmatrix[i]*info->sat) >> 7;
+   matrix[i] = (info->fmt->cmatrix[i] * sat) >> 7;
/*
 * Then, if need be, rotate the hue value.
 */
-   if (info->hue != 0) {
+   if (hue != 0) {
int sinth, costh, tmpmatrix[CMATRIX_LEN];
 
memcpy(tmpmatrix, matrix, CMATRIX_LEN*sizeof(int));
-   sinth = ov7670_sine(info->hue);
-   costh = ov7670_cosine(info->hue);
+   sinth = ov7670_sine(hue);
+   costh = ov7670_cosine(hue);
 
matrix[0] = (matrix[3]*sinth + matrix[0]*costh)/1000;
matrix[1] = (matrix[4]*sinth + matrix[1]*costh)/1000;
@@ -1224,60 +1244,21 @@ static void ov7670_calc_cmatrix(struct ov7670_info 
*info,
 
 
 
-static int ov7670_s_sat(struct v4l2_subdev *sd, int value)
+static int ov7670_s_sat_hue(struct v4l2_subdev *sd, int sat, int hue)
 {
struct ov7670_info *info = to_state(sd);
int matrix[CMATRIX_LEN];
int ret;
 
-   info->sat = value;
-   ov7670_calc_cmatrix(info, matrix);
+   ov7670_calc_cmatrix(info, matrix, sat, hue);
ret = ov7670_store_cmatrix(sd, matrix);
return ret;
 }
 
-static int ov7670_g_sat(struct v4l2_subdev *sd, __s32 *value)
-{
-   struct ov7670_info *info = to_state(sd);
-
-   *value = info->sat;
-   return 0;
-}
-
-static int ov7670_s_hue(struct v4l2_subdev *sd, int value)
-{
-   struct ov7670_info *info = to_state(sd);
-   int matrix[CMATRIX_LEN];
-   int ret;
-
-   if (value < -180 || value > 180)
-   return -EINVAL;
-   info->hue = value;
-   ov7670_calc_cmatrix(info, matrix);
-   ret = ov7670_store_cmatrix(sd, matrix);
-   return ret;
-}
-
-
-static int ov7670_g_hue(struct v4l2_subdev *sd, __s32 *value)
-{
-   struct ov7670_info *info = to_state(sd);
-
-   *value = info->hue;
-   return 0;
-}
-
 
 /*
  * Some weird registers seem to store values in a sign/magnitude format!
  */
-static unsigned char ov7670_sm_to_abs(unsigned char v)
-{
-   if ((v & 0x80) == 0)
-   return v + 128;
-   return 128 - (v & 0x7f);
-}
-
 
 static unsigned char ov7670_abs_to_sm(unsigned char v)
 {
@@ -1299,40 +1280,11 @@ static int ov7670_s_brightness(struct v4l2_subdev *sd, 
int value)
return ret;
 }
 
-static int ov7670_g_brightness(struct v4l2_subdev *sd, __s32 *value)
-{
-   unsigned char v = 0;
-   int ret = ov7670_read(sd, REG_BRIGHT, &v);
-
-   *value = ov7670_sm_to_abs(v);
-   return ret;
-}
-
 static int ov7670_s_contrast(struct v4l2_subdev *sd, int value)
 {
return ov7670_write(sd, REG_CONTRAS, (unsigned char) value);
 }
 
-static int ov7670_g_contrast(struct v

[PATCH v3 0/4] ov7670: migrate this sensor and its users to ctrl framework.

2012-09-28 Thread Javier Martin
The following series migrate ov7670 sensor and current users to ctrl framework
as  discussed in [1]. This has been tested against mx2_camera soc-camera bridge,
so tests or acks will be required from people using cam-core and via-camera out
there.

This will have to be applied on top of my previous series:

[PATCH v2 0/5] media: ov7670: driver cleanup and support for ov7674.


All submitted patches have been obtained from Hans' tree and slightly modified
to apply on current media_tree for-v3.7 branch:

http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/cafe-ctrl

Changes since v2:
 - See changelog in patch 1.

[PATCH v3 1/4] ov7670: use the control framework
[PATCH v3 2/4] mcam-core: implement the control framework.
[PATCH v3 3/4] via-camera: implement the control framework.
[PATCH v3 4/4] ov7670: remove legacy ctrl callbacks.

[1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg51778.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


[RFCv2 PATCH] tuner-core: map audmode to STEREO for radio devices.

2012-09-28 Thread Hans Verkuil
Changes since RFCv1:

- Improved the commit text
- Changed 'if (t->audmode > V4L2_TUNER_MODE_STEREO)' as suggested by Mauro.
- Update t->audmode after having called the tuner driver, allowing the tuner
  driver to modify audmode if it only supports mono.

Regards,

Hans

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


[RFCv2 PATCH] tuner-core: map audmode to STEREO for radio devices.

2012-09-28 Thread Hans Verkuil
From: Hans Verkuil 

Fixes a v4l2-compliance error: setting audmode to a value other than mono
or stereo for a radio device should map to MODE_STEREO.

The spec specifies that for radio devices only mono and stereo audmodes are
valid. If the user specifies another audmode in v4l2_tuner, then that should
be mapped to valid audmode. That didn't happen here.

Note that tuner drivers might decide to limit the possible audmode even
further if it only supports mono. In that case the tuner driver can set
audmode to mono. However, that new value wasn't copied back to t->audmode,
and that has been fixed as well in this patch.

Signed-off-by: Hans Verkuil 
---
 drivers/media/v4l2-core/tuner-core.c |   17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/media/v4l2-core/tuner-core.c 
b/drivers/media/v4l2-core/tuner-core.c
index b5a819a..b5a8aac 100644
--- a/drivers/media/v4l2-core/tuner-core.c
+++ b/drivers/media/v4l2-core/tuner-core.c
@@ -1013,6 +1013,11 @@ static void set_radio_freq(struct i2c_client *c, 
unsigned int freq)
t->standby = false;
 
analog_ops->set_params(&t->fe, ¶ms);
+   /*
+* The tuner driver might decide to change the audmode if it only
+* supports stereo, so update t->audmode.
+*/
+   t->audmode = params.audmode;
 }
 
 /*
@@ -1235,8 +1240,18 @@ static int tuner_s_tuner(struct v4l2_subdev *sd, struct 
v4l2_tuner *vt)
if (set_mode(t, vt->type))
return 0;
 
-   if (t->mode == V4L2_TUNER_RADIO)
+   if (t->mode == V4L2_TUNER_RADIO) {
t->audmode = vt->audmode;
+   /*
+* For radio audmode can only be mono or stereo. Map any
+* other values to stereo. The actual tuner driver that is
+* called in set_radio_freq can decide to limit the audmode to
+* mono if only mono is supported.
+*/
+   if (t->audmode != V4L2_TUNER_MODE_MONO &&
+   t->audmode != V4L2_TUNER_MODE_STEREO)
+   t->audmode = V4L2_TUNER_MODE_STEREO;
+   }
set_freq(t, 0);
 
return 0;
-- 
1.7.10.4

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


Re: [PATCH 2/2] V4L: soc_camera: disable I2C subdev streamon for mpc52xx_csi

2012-09-28 Thread Guennadi Liakhovetski
Hi Anatolij

On Fri, 28 Sep 2012, Anatolij Gustschin wrote:

> With mpc52xx_csi interface I2C subdev streamon after vb2_streamon()
> doesn't work due to mpc52xx sensor interface glue-logic restrictions.
> 
> Since mpc5200 doesn't have a camera sensor interface, the sensor on
> O2D cameras is connected to the LocalPlus bus by special glue-logic.
> While sensor read-out the sensor will be clocked with the bus chip-
> select signal as the sensor clock so that the read-out is synchronous
> with the data accesses on the bus. Therefore, I2C access can't be
> performed when the glue-logic is setup for sensor read-out.
> 
> mpc52xx_csi driver for O2D cameras performs I2C subdev streamon in
> its start_streaming() operation and then disables the I2C bus access
> by configuring the interface glue-logic for sensor read-out.
> For above-mentioned reasons we disable this subdev call here.
> 
> Signed-off-by: Anatolij Gustschin 
> ---
>  drivers/media/platform/soc_camera/soc_camera.c |5 -
>  1 files changed, 4 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/media/platform/soc_camera/soc_camera.c 
> b/drivers/media/platform/soc_camera/soc_camera.c
> index f6b1c1f..64e0abb 100644
> --- a/drivers/media/platform/soc_camera/soc_camera.c
> +++ b/drivers/media/platform/soc_camera/soc_camera.c
> @@ -809,7 +809,7 @@ static int soc_camera_streamon(struct file *file, void 
> *priv,
>  {
>   struct soc_camera_device *icd = file->private_data;
>   struct soc_camera_host *ici = to_soc_camera_host(icd->parent);
> - struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
> + struct v4l2_subdev __maybe_unused *sd = soc_camera_to_subdev(icd);
>   int ret;
>  
>   WARN_ON(priv != file->private_data);
> @@ -826,8 +826,11 @@ static int soc_camera_streamon(struct file *file, void 
> *priv,
>   else
>   ret = vb2_streamon(&icd->vb2_vidq, i);
>  
> +#if !defined(CONFIG_VIDEO_MPC52xx_CSI) && \
> +!defined(CONFIG_VIDEO_MPC52xx_CSI_MODULE)

No, we're not adding any preprocessor or run-time hardware dependencies to 
soc-camera or to any other generic code. I have no idea what those "IFM 
O2D" cameras are. If it's their common feature, that they cannot take any 
further I2C commands, while streaming, their drivers have to do that 
themselves. And not only for stream-on, there are many operations, that 
are allowed during streaming.

Thanks
Guennadi

>   if (!ret)
>   v4l2_subdev_call(sd, video, s_stream, 1);
> +#endif
>  
>   return ret;
>  }
> -- 
> 1.7.1
> 

---
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 v2 1/4] ov7670: use the control framework

2012-09-28 Thread javier Martin
Hi Hans,

On 28 September 2012 13:05, Hans Verkuil  wrote:
> On Fri September 28 2012 12:50:55 Javier Martin wrote:
>> Signed-off-by: Hans Verkuil 
>> Signed-off-by: Javier Martin 
>> ---
>> Changes since v1:
>>  - Use v4l2_ctrl_auto_cluster() for auto_gain and auto_exp.
>>
>> ---
>>  drivers/media/i2c/ov7670.c |  310 
>> 
>>  1 file changed, 112 insertions(+), 198 deletions(-)
>>
>> diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
>> index 9d7a92e..babd55c 100644
>> --- a/drivers/media/i2c/ov7670.c
>> +++ b/drivers/media/i2c/ov7670.c
>> @@ -18,6 +18,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>
>> @@ -222,9 +223,23 @@ struct ov7670_devtype {
>>  struct ov7670_format_struct;  /* coming later */
>>  struct ov7670_info {
>>   struct v4l2_subdev sd;
>> + struct v4l2_ctrl_handler hdl;
>> + struct {
>> + /* gain cluster */
>> + struct v4l2_ctrl *auto_gain;
>> + struct v4l2_ctrl *gain;
>> + };
>> + struct {
>> + /* exposure cluster */
>> + struct v4l2_ctrl *auto_exposure;
>> + struct v4l2_ctrl *exposure;
>> + };
>> + struct {
>> + /* saturation/hue cluster */
>> + struct v4l2_ctrl *saturation;
>> + struct v4l2_ctrl *hue;
>> + };
>>   struct ov7670_format_struct *fmt;  /* Current format */
>> - unsigned char sat;  /* Saturation value */
>> - int hue;/* Hue value */
>>   int min_width;  /* Filter out smaller sizes */
>>   int min_height; /* Filter out smaller sizes */
>>   int clock_speed;/* External clock speed (MHz) */
>> @@ -240,6 +255,11 @@ static inline struct ov7670_info *to_state(struct 
>> v4l2_subdev *sd)
>>   return container_of(sd, struct ov7670_info, sd);
>>  }
>>
>> +static inline struct v4l2_subdev *to_sd(struct v4l2_ctrl *ctrl)
>> +{
>> + return &container_of(ctrl->handler, struct ov7670_info, hdl)->sd;
>> +}
>> +
>>
>>
>>  /*
>> @@ -1195,23 +1215,23 @@ static int ov7670_cosine(int theta)
>>
>>
>>  static void ov7670_calc_cmatrix(struct ov7670_info *info,
>> - int matrix[CMATRIX_LEN])
>> + int matrix[CMATRIX_LEN], int sat, int hue)
>>  {
>>   int i;
>>   /*
>>* Apply the current saturation setting first.
>>*/
>>   for (i = 0; i < CMATRIX_LEN; i++)
>> - matrix[i] = (info->fmt->cmatrix[i]*info->sat) >> 7;
>> + matrix[i] = (info->fmt->cmatrix[i] * sat) >> 7;
>>   /*
>>* Then, if need be, rotate the hue value.
>>*/
>> - if (info->hue != 0) {
>> + if (hue != 0) {
>>   int sinth, costh, tmpmatrix[CMATRIX_LEN];
>>
>>   memcpy(tmpmatrix, matrix, CMATRIX_LEN*sizeof(int));
>> - sinth = ov7670_sine(info->hue);
>> - costh = ov7670_cosine(info->hue);
>> + sinth = ov7670_sine(hue);
>> + costh = ov7670_cosine(hue);
>>
>>   matrix[0] = (matrix[3]*sinth + matrix[0]*costh)/1000;
>>   matrix[1] = (matrix[4]*sinth + matrix[1]*costh)/1000;
>> @@ -1224,60 +1244,21 @@ static void ov7670_calc_cmatrix(struct ov7670_info 
>> *info,
>>
>>
>>
>> -static int ov7670_s_sat(struct v4l2_subdev *sd, int value)
>> +static int ov7670_s_sat_hue(struct v4l2_subdev *sd, int sat, int hue)
>>  {
>>   struct ov7670_info *info = to_state(sd);
>>   int matrix[CMATRIX_LEN];
>>   int ret;
>>
>> - info->sat = value;
>> - ov7670_calc_cmatrix(info, matrix);
>> + ov7670_calc_cmatrix(info, matrix, sat, hue);
>>   ret = ov7670_store_cmatrix(sd, matrix);
>>   return ret;
>>  }
>>
>> -static int ov7670_g_sat(struct v4l2_subdev *sd, __s32 *value)
>> -{
>> - struct ov7670_info *info = to_state(sd);
>> -
>> - *value = info->sat;
>> - return 0;
>> -}
>> -
>> -static int ov7670_s_hue(struct v4l2_subdev *sd, int value)
>> -{
>> - struct ov7670_info *info = to_state(sd);
>> - int matrix[CMATRIX_LEN];
>> - int ret;
>> -
>> - if (value < -180 || value > 180)
>> - return -EINVAL;
>> - info->hue = value;
>> - ov7670_calc_cmatrix(info, matrix);
>> - ret = ov7670_store_cmatrix(sd, matrix);
>> - return ret;
>> -}
>> -
>> -
>> -static int ov7670_g_hue(struct v4l2_subdev *sd, __s32 *value)
>> -{
>> - struct ov7670_info *info = to_state(sd);
>> -
>> - *value = info->hue;
>> - return 0;
>> -}
>> -
>>
>>  /*
>>   * Some weird registers seem to store values in a sign/magnitude format!
>>   */
>> -static unsigned char ov7670_sm_to_abs(unsigned char v)
>> -{
>> - if ((v & 0x80) == 0)
>> - return v + 128;
>> - return 128 - (v & 0x7f);
>> -}
>> -
>>
>>  static unsigned char ov7670_abs_to_sm(unsigned char v)
>>  {
>> @@ -1299,40 +1280,11 @@ static int ov7670_s_brightness(struct v4l2_subdev 
>> *sd, int v

[GIT PULL FOR v3.7] Two control framework enhancements

2012-09-28 Thread Hans Verkuil
This pull request adds two new features to the control framework:

- a notify function that is needed to have a bridge driver be notified of
  subdevice control changes
- a new filter function to have more control over which controls are added
  by v4l2_ctrl_add_handler.

Both of these features are used by upcoming driver conversions (bttv, em28xx,
others).

Although Laurent had some comments I disagreed with them (see:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg52708.html).

Laurent is OK with that.

This pull request is identical to my previous pull request, except for being
rebased to the latest v3.7 code.

Regards,

Hans

The following changes since commit 8928b6d1568eb9104cc9e2e6627d7086437b2fb3:

  [media] media: mx2_camera: use managed functions to clean up code (2012-09-27 
15:56:47 -0300)

are available in the git repository at:

  git://linuxtv.org/hverkuil/media_tree.git ctrlfw

for you to fetch changes up to 9983a1138bc7bed3dae801db430478effcc997c6:

  v4l2-ctrls: add a filter function to v4l2_ctrl_add_handler. (2012-09-28 
13:05:34 +0200)


Hans Verkuil (2):
  v4l2-ctrls: add a notify callback.
  v4l2-ctrls: add a filter function to v4l2_ctrl_add_handler.

 Documentation/video4linux/v4l2-controls.txt|   28 
+++-
 drivers/media/pci/cx88/cx88-blackbird.c|2 +-
 drivers/media/pci/cx88/cx88-video.c|2 +-
 drivers/media/platform/s5p-fimc/fimc-capture.c |2 +-
 drivers/media/platform/soc_camera/soc_camera.c |2 +-
 drivers/media/v4l2-core/v4l2-ctrls.c   |   50 
+-
 drivers/media/v4l2-core/v4l2-device.c  |2 +-
 include/media/v4l2-ctrls.h |   43 
+--
 8 files changed, 114 insertions(+), 17 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 1/4] ov7670: use the control framework

2012-09-28 Thread Hans Verkuil
On Fri September 28 2012 12:50:55 Javier Martin wrote:
> Signed-off-by: Hans Verkuil 
> Signed-off-by: Javier Martin 
> ---
> Changes since v1:
>  - Use v4l2_ctrl_auto_cluster() for auto_gain and auto_exp.
> 
> ---
>  drivers/media/i2c/ov7670.c |  310 
> 
>  1 file changed, 112 insertions(+), 198 deletions(-)
> 
> diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
> index 9d7a92e..babd55c 100644
> --- a/drivers/media/i2c/ov7670.c
> +++ b/drivers/media/i2c/ov7670.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -222,9 +223,23 @@ struct ov7670_devtype {
>  struct ov7670_format_struct;  /* coming later */
>  struct ov7670_info {
>   struct v4l2_subdev sd;
> + struct v4l2_ctrl_handler hdl;
> + struct {
> + /* gain cluster */
> + struct v4l2_ctrl *auto_gain;
> + struct v4l2_ctrl *gain;
> + };
> + struct {
> + /* exposure cluster */
> + struct v4l2_ctrl *auto_exposure;
> + struct v4l2_ctrl *exposure;
> + };
> + struct {
> + /* saturation/hue cluster */
> + struct v4l2_ctrl *saturation;
> + struct v4l2_ctrl *hue;
> + };
>   struct ov7670_format_struct *fmt;  /* Current format */
> - unsigned char sat;  /* Saturation value */
> - int hue;/* Hue value */
>   int min_width;  /* Filter out smaller sizes */
>   int min_height; /* Filter out smaller sizes */
>   int clock_speed;/* External clock speed (MHz) */
> @@ -240,6 +255,11 @@ static inline struct ov7670_info *to_state(struct 
> v4l2_subdev *sd)
>   return container_of(sd, struct ov7670_info, sd);
>  }
>  
> +static inline struct v4l2_subdev *to_sd(struct v4l2_ctrl *ctrl)
> +{
> + return &container_of(ctrl->handler, struct ov7670_info, hdl)->sd;
> +}
> +
>  
>  
>  /*
> @@ -1195,23 +1215,23 @@ static int ov7670_cosine(int theta)
>  
>  
>  static void ov7670_calc_cmatrix(struct ov7670_info *info,
> - int matrix[CMATRIX_LEN])
> + int matrix[CMATRIX_LEN], int sat, int hue)
>  {
>   int i;
>   /*
>* Apply the current saturation setting first.
>*/
>   for (i = 0; i < CMATRIX_LEN; i++)
> - matrix[i] = (info->fmt->cmatrix[i]*info->sat) >> 7;
> + matrix[i] = (info->fmt->cmatrix[i] * sat) >> 7;
>   /*
>* Then, if need be, rotate the hue value.
>*/
> - if (info->hue != 0) {
> + if (hue != 0) {
>   int sinth, costh, tmpmatrix[CMATRIX_LEN];
>  
>   memcpy(tmpmatrix, matrix, CMATRIX_LEN*sizeof(int));
> - sinth = ov7670_sine(info->hue);
> - costh = ov7670_cosine(info->hue);
> + sinth = ov7670_sine(hue);
> + costh = ov7670_cosine(hue);
>  
>   matrix[0] = (matrix[3]*sinth + matrix[0]*costh)/1000;
>   matrix[1] = (matrix[4]*sinth + matrix[1]*costh)/1000;
> @@ -1224,60 +1244,21 @@ static void ov7670_calc_cmatrix(struct ov7670_info 
> *info,
>  
>  
>  
> -static int ov7670_s_sat(struct v4l2_subdev *sd, int value)
> +static int ov7670_s_sat_hue(struct v4l2_subdev *sd, int sat, int hue)
>  {
>   struct ov7670_info *info = to_state(sd);
>   int matrix[CMATRIX_LEN];
>   int ret;
>  
> - info->sat = value;
> - ov7670_calc_cmatrix(info, matrix);
> + ov7670_calc_cmatrix(info, matrix, sat, hue);
>   ret = ov7670_store_cmatrix(sd, matrix);
>   return ret;
>  }
>  
> -static int ov7670_g_sat(struct v4l2_subdev *sd, __s32 *value)
> -{
> - struct ov7670_info *info = to_state(sd);
> -
> - *value = info->sat;
> - return 0;
> -}
> -
> -static int ov7670_s_hue(struct v4l2_subdev *sd, int value)
> -{
> - struct ov7670_info *info = to_state(sd);
> - int matrix[CMATRIX_LEN];
> - int ret;
> -
> - if (value < -180 || value > 180)
> - return -EINVAL;
> - info->hue = value;
> - ov7670_calc_cmatrix(info, matrix);
> - ret = ov7670_store_cmatrix(sd, matrix);
> - return ret;
> -}
> -
> -
> -static int ov7670_g_hue(struct v4l2_subdev *sd, __s32 *value)
> -{
> - struct ov7670_info *info = to_state(sd);
> -
> - *value = info->hue;
> - return 0;
> -}
> -
>  
>  /*
>   * Some weird registers seem to store values in a sign/magnitude format!
>   */
> -static unsigned char ov7670_sm_to_abs(unsigned char v)
> -{
> - if ((v & 0x80) == 0)
> - return v + 128;
> - return 128 - (v & 0x7f);
> -}
> -
>  
>  static unsigned char ov7670_abs_to_sm(unsigned char v)
>  {
> @@ -1299,40 +1280,11 @@ static int ov7670_s_brightness(struct v4l2_subdev 
> *sd, int value)
>   return ret;
>  }
>  
> -static int ov7670_g_brightness(struct v4l2_subdev *sd, __s32 *value)
> -{
> - unsigned char v = 0;
> - int ret = ov7670_read(sd, REG_BRIGHT,

[PATCH 15/14] OF: define of_*_cmp() macros also if CONFIG_OF isn't set

2012-09-28 Thread Guennadi Liakhovetski
of_*_cmp() macros do not depend on any OF functions and can be defined also
if CONFIG_OF isn't set. Also include linux/string.h, required by those
macros.

Signed-off-by: Guennadi Liakhovetski 
---

These definitions are also required for "# CONFIG_OF is not set" builds.

 include/linux/of.h |   15 ---
 1 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/include/linux/of.h b/include/linux/of.h
index 3636fae..ad2e79b 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -85,6 +85,14 @@ static inline struct device_node *of_node_get(struct 
device_node *node)
 static inline void of_node_put(struct device_node *node) { }
 #endif /* !CONFIG_OF_DYNAMIC */
 
+/* Default string compare functions, Allow arch asm/prom.h to override */
+#if !defined(of_compat_cmp)
+#include 
+#define of_compat_cmp(s1, s2, l)   strcasecmp((s1), (s2))
+#define of_prop_cmp(s1, s2)strcmp((s1), (s2))
+#define of_node_cmp(s1, s2)strcasecmp((s1), (s2))
+#endif
+
 #ifdef CONFIG_OF
 
 /* Pointer for first entry in chain of all nodes. */
@@ -143,13 +151,6 @@ static inline unsigned long of_read_ulong(const __be32 
*cell, int size)
 #define OF_ROOT_NODE_SIZE_CELLS_DEFAULT 1
 #endif
 
-/* Default string compare functions, Allow arch asm/prom.h to override */
-#if !defined(of_compat_cmp)
-#define of_compat_cmp(s1, s2, l)   strcasecmp((s1), (s2))
-#define of_prop_cmp(s1, s2)strcmp((s1), (s2))
-#define of_node_cmp(s1, s2)strcasecmp((s1), (s2))
-#endif
-
 /* flag descriptions */
 #define OF_DYNAMIC 1 /* node and properties were allocated via kmalloc */
 #define OF_DETACHED2 /* node has been detached from the device tree */
-- 
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 4/4] ov7670: remove legacy ctrl callbacks.

2012-09-28 Thread Javier Martin
via-camera and mcam-core were the only bridge drivers that used ov7670.
Since now they have been moved to use the ctrl framework, the old
legacy callbacks in the ov7670 can be removed.

Signed-off-by: Javier Martin 
---
 drivers/media/i2c/ov7670.c |7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index babd55c..113a4f3 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -1504,13 +1504,6 @@ static int ov7670_s_register(struct v4l2_subdev *sd, 
struct v4l2_dbg_register *r
 
 static const struct v4l2_subdev_core_ops ov7670_core_ops = {
.g_chip_ident = ov7670_g_chip_ident,
-   .g_ext_ctrls = v4l2_subdev_g_ext_ctrls,
-   .try_ext_ctrls = v4l2_subdev_try_ext_ctrls,
-   .s_ext_ctrls = v4l2_subdev_s_ext_ctrls,
-   .g_ctrl = v4l2_subdev_g_ctrl,
-   .s_ctrl = v4l2_subdev_s_ctrl,
-   .queryctrl = v4l2_subdev_queryctrl,
-   .querymenu = v4l2_subdev_querymenu,
.reset = ov7670_reset,
.init = ov7670_init,
 #ifdef CONFIG_VIDEO_ADV_DEBUG
-- 
1.7.9.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 3/4] via-camera: implement the control framework.

2012-09-28 Thread Javier Martin
And added a missing kfree to clean up the via_camera struct.

Signed-off-by: Hans Verkuil 
Signed-off-by: Javier Martin 
---
 drivers/media/platform/via-camera.c |   60 ---
 1 file changed, 14 insertions(+), 46 deletions(-)

diff --git a/drivers/media/platform/via-camera.c 
b/drivers/media/platform/via-camera.c
index eb404c2..1b5f97d 100644
--- a/drivers/media/platform/via-camera.c
+++ b/drivers/media/platform/via-camera.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -63,6 +64,7 @@ enum viacam_opstate { S_IDLE = 0, S_RUNNING = 1 };
 
 struct via_camera {
struct v4l2_device v4l2_dev;
+   struct v4l2_ctrl_handler ctrl_handler;
struct video_device vdev;
struct v4l2_subdev *sensor;
struct platform_device *platdev;
@@ -818,47 +820,6 @@ static int viacam_g_chip_ident(struct file *file, void 
*priv,
 }
 
 /*
- * Control ops are passed through to the sensor.
- */
-static int viacam_queryctrl(struct file *filp, void *priv,
-   struct v4l2_queryctrl *qc)
-{
-   struct via_camera *cam = priv;
-   int ret;
-
-   mutex_lock(&cam->lock);
-   ret = sensor_call(cam, core, queryctrl, qc);
-   mutex_unlock(&cam->lock);
-   return ret;
-}
-
-
-static int viacam_g_ctrl(struct file *filp, void *priv,
-   struct v4l2_control *ctrl)
-{
-   struct via_camera *cam = priv;
-   int ret;
-
-   mutex_lock(&cam->lock);
-   ret = sensor_call(cam, core, g_ctrl, ctrl);
-   mutex_unlock(&cam->lock);
-   return ret;
-}
-
-
-static int viacam_s_ctrl(struct file *filp, void *priv,
-   struct v4l2_control *ctrl)
-{
-   struct via_camera *cam = priv;
-   int ret;
-
-   mutex_lock(&cam->lock);
-   ret = sensor_call(cam, core, s_ctrl, ctrl);
-   mutex_unlock(&cam->lock);
-   return ret;
-}
-
-/*
  * Only one input.
  */
 static int viacam_enum_input(struct file *filp, void *priv,
@@ -1214,9 +1175,6 @@ static int viacam_enum_frameintervals(struct file *filp, 
void *priv,
 
 static const struct v4l2_ioctl_ops viacam_ioctl_ops = {
.vidioc_g_chip_ident= viacam_g_chip_ident,
-   .vidioc_queryctrl   = viacam_queryctrl,
-   .vidioc_g_ctrl  = viacam_g_ctrl,
-   .vidioc_s_ctrl  = viacam_s_ctrl,
.vidioc_enum_input  = viacam_enum_input,
.vidioc_g_input = viacam_g_input,
.vidioc_s_input = viacam_s_input,
@@ -1418,8 +1376,12 @@ static __devinit int viacam_probe(struct platform_device 
*pdev)
ret = v4l2_device_register(&pdev->dev, &cam->v4l2_dev);
if (ret) {
dev_err(&pdev->dev, "Unable to register v4l2 device\n");
-   return ret;
+   goto out_free;
}
+   ret = v4l2_ctrl_handler_init(&cam->ctrl_handler, 10);
+   if (ret)
+   goto out_unregister;
+   cam->v4l2_dev.ctrl_handler = &cam->ctrl_handler;
/*
 * Convince the system that we can do DMA.
 */
@@ -1436,7 +1398,7 @@ static __devinit int viacam_probe(struct platform_device 
*pdev)
 */
ret = via_sensor_power_setup(cam);
if (ret)
-   goto out_unregister;
+   goto out_ctrl_hdl_free;
via_sensor_power_up(cam);
 
/*
@@ -1485,8 +1447,12 @@ out_irq:
free_irq(viadev->pdev->irq, cam);
 out_power_down:
via_sensor_power_release(cam);
+out_ctrl_hdl_free:
+   v4l2_ctrl_handler_free(&cam->ctrl_handler);
 out_unregister:
v4l2_device_unregister(&cam->v4l2_dev);
+out_free:
+   kfree(cam);
return ret;
 }
 
@@ -1499,6 +1465,8 @@ static __devexit int viacam_remove(struct platform_device 
*pdev)
v4l2_device_unregister(&cam->v4l2_dev);
free_irq(viadev->pdev->irq, cam);
via_sensor_power_release(cam);
+   v4l2_ctrl_handler_free(&cam->ctrl_handler);
+   kfree(cam);
via_cam_info = NULL;
return 0;
 }
-- 
1.7.9.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 2/4] mcam-core: implement the control framework.

2012-09-28 Thread Javier Martin
Signed-off-by: Hans Verkuil 
Signed-off-by: Javier Martin 
---
 drivers/media/platform/marvell-ccic/mcam-core.c |   54 ---
 drivers/media/platform/marvell-ccic/mcam-core.h |2 +
 2 files changed, 11 insertions(+), 45 deletions(-)

diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c 
b/drivers/media/platform/marvell-ccic/mcam-core.c
index ce2b7b4..568f8a5 100644
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1232,47 +1233,6 @@ static int mcam_vidioc_dqbuf(struct file *filp, void 
*priv,
return ret;
 }
 
-
-
-static int mcam_vidioc_queryctrl(struct file *filp, void *priv,
-   struct v4l2_queryctrl *qc)
-{
-   struct mcam_camera *cam = priv;
-   int ret;
-
-   mutex_lock(&cam->s_mutex);
-   ret = sensor_call(cam, core, queryctrl, qc);
-   mutex_unlock(&cam->s_mutex);
-   return ret;
-}
-
-
-static int mcam_vidioc_g_ctrl(struct file *filp, void *priv,
-   struct v4l2_control *ctrl)
-{
-   struct mcam_camera *cam = priv;
-   int ret;
-
-   mutex_lock(&cam->s_mutex);
-   ret = sensor_call(cam, core, g_ctrl, ctrl);
-   mutex_unlock(&cam->s_mutex);
-   return ret;
-}
-
-
-static int mcam_vidioc_s_ctrl(struct file *filp, void *priv,
-   struct v4l2_control *ctrl)
-{
-   struct mcam_camera *cam = priv;
-   int ret;
-
-   mutex_lock(&cam->s_mutex);
-   ret = sensor_call(cam, core, s_ctrl, ctrl);
-   mutex_unlock(&cam->s_mutex);
-   return ret;
-}
-
-
 static int mcam_vidioc_querycap(struct file *file, void *priv,
struct v4l2_capability *cap)
 {
@@ -1520,9 +1480,6 @@ static const struct v4l2_ioctl_ops mcam_v4l_ioctl_ops = {
.vidioc_dqbuf   = mcam_vidioc_dqbuf,
.vidioc_streamon= mcam_vidioc_streamon,
.vidioc_streamoff   = mcam_vidioc_streamoff,
-   .vidioc_queryctrl   = mcam_vidioc_queryctrl,
-   .vidioc_g_ctrl  = mcam_vidioc_g_ctrl,
-   .vidioc_s_ctrl  = mcam_vidioc_s_ctrl,
.vidioc_g_parm  = mcam_vidioc_g_parm,
.vidioc_s_parm  = mcam_vidioc_s_parm,
.vidioc_enum_framesizes = mcam_vidioc_enum_framesizes,
@@ -1786,14 +1743,19 @@ int mccic_register(struct mcam_camera *cam)
/*
 * Get the v4l2 setup done.
 */
+   ret = v4l2_ctrl_handler_init(&cam->ctrl_handler, 10);
+   if (ret)
+   goto out_unregister;
+   cam->v4l2_dev.ctrl_handler = &cam->ctrl_handler;
+
mutex_lock(&cam->s_mutex);
cam->vdev = mcam_v4l_template;
cam->vdev.debug = 0;
cam->vdev.v4l2_dev = &cam->v4l2_dev;
+   video_set_drvdata(&cam->vdev, cam);
ret = video_register_device(&cam->vdev, VFL_TYPE_GRABBER, -1);
if (ret)
goto out;
-   video_set_drvdata(&cam->vdev, cam);
 
/*
 * If so requested, try to get our DMA buffers now.
@@ -1805,6 +1767,7 @@ int mccic_register(struct mcam_camera *cam)
}
 
 out:
+   v4l2_ctrl_handler_free(&cam->ctrl_handler);
mutex_unlock(&cam->s_mutex);
return ret;
 out_unregister:
@@ -1829,6 +1792,7 @@ void mccic_shutdown(struct mcam_camera *cam)
if (cam->buffer_mode == B_vmalloc)
mcam_free_dma_bufs(cam);
video_unregister_device(&cam->vdev);
+   v4l2_ctrl_handler_free(&cam->ctrl_handler);
v4l2_device_unregister(&cam->v4l2_dev);
 }
 
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.h 
b/drivers/media/platform/marvell-ccic/mcam-core.h
index bd6acba..f7c34ab 100644
--- a/drivers/media/platform/marvell-ccic/mcam-core.h
+++ b/drivers/media/platform/marvell-ccic/mcam-core.h
@@ -8,6 +8,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -104,6 +105,7 @@ struct mcam_camera {
 * should not be touched by the platform code.
 */
struct v4l2_device v4l2_dev;
+   struct v4l2_ctrl_handler ctrl_handler;
enum mcam_state state;
unsigned long flags;/* Buffer status, mainly (dev_lock) */
int users;  /* How many open FDs */
-- 
1.7.9.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 1/4] ov7670: use the control framework

2012-09-28 Thread Javier Martin
Signed-off-by: Hans Verkuil 
Signed-off-by: Javier Martin 
---
Changes since v1:
 - Use v4l2_ctrl_auto_cluster() for auto_gain and auto_exp.

---
 drivers/media/i2c/ov7670.c |  310 
 1 file changed, 112 insertions(+), 198 deletions(-)

diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index 9d7a92e..babd55c 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -222,9 +223,23 @@ struct ov7670_devtype {
 struct ov7670_format_struct;  /* coming later */
 struct ov7670_info {
struct v4l2_subdev sd;
+   struct v4l2_ctrl_handler hdl;
+   struct {
+   /* gain cluster */
+   struct v4l2_ctrl *auto_gain;
+   struct v4l2_ctrl *gain;
+   };
+   struct {
+   /* exposure cluster */
+   struct v4l2_ctrl *auto_exposure;
+   struct v4l2_ctrl *exposure;
+   };
+   struct {
+   /* saturation/hue cluster */
+   struct v4l2_ctrl *saturation;
+   struct v4l2_ctrl *hue;
+   };
struct ov7670_format_struct *fmt;  /* Current format */
-   unsigned char sat;  /* Saturation value */
-   int hue;/* Hue value */
int min_width;  /* Filter out smaller sizes */
int min_height; /* Filter out smaller sizes */
int clock_speed;/* External clock speed (MHz) */
@@ -240,6 +255,11 @@ static inline struct ov7670_info *to_state(struct 
v4l2_subdev *sd)
return container_of(sd, struct ov7670_info, sd);
 }
 
+static inline struct v4l2_subdev *to_sd(struct v4l2_ctrl *ctrl)
+{
+   return &container_of(ctrl->handler, struct ov7670_info, hdl)->sd;
+}
+
 
 
 /*
@@ -1195,23 +1215,23 @@ static int ov7670_cosine(int theta)
 
 
 static void ov7670_calc_cmatrix(struct ov7670_info *info,
-   int matrix[CMATRIX_LEN])
+   int matrix[CMATRIX_LEN], int sat, int hue)
 {
int i;
/*
 * Apply the current saturation setting first.
 */
for (i = 0; i < CMATRIX_LEN; i++)
-   matrix[i] = (info->fmt->cmatrix[i]*info->sat) >> 7;
+   matrix[i] = (info->fmt->cmatrix[i] * sat) >> 7;
/*
 * Then, if need be, rotate the hue value.
 */
-   if (info->hue != 0) {
+   if (hue != 0) {
int sinth, costh, tmpmatrix[CMATRIX_LEN];
 
memcpy(tmpmatrix, matrix, CMATRIX_LEN*sizeof(int));
-   sinth = ov7670_sine(info->hue);
-   costh = ov7670_cosine(info->hue);
+   sinth = ov7670_sine(hue);
+   costh = ov7670_cosine(hue);
 
matrix[0] = (matrix[3]*sinth + matrix[0]*costh)/1000;
matrix[1] = (matrix[4]*sinth + matrix[1]*costh)/1000;
@@ -1224,60 +1244,21 @@ static void ov7670_calc_cmatrix(struct ov7670_info 
*info,
 
 
 
-static int ov7670_s_sat(struct v4l2_subdev *sd, int value)
+static int ov7670_s_sat_hue(struct v4l2_subdev *sd, int sat, int hue)
 {
struct ov7670_info *info = to_state(sd);
int matrix[CMATRIX_LEN];
int ret;
 
-   info->sat = value;
-   ov7670_calc_cmatrix(info, matrix);
+   ov7670_calc_cmatrix(info, matrix, sat, hue);
ret = ov7670_store_cmatrix(sd, matrix);
return ret;
 }
 
-static int ov7670_g_sat(struct v4l2_subdev *sd, __s32 *value)
-{
-   struct ov7670_info *info = to_state(sd);
-
-   *value = info->sat;
-   return 0;
-}
-
-static int ov7670_s_hue(struct v4l2_subdev *sd, int value)
-{
-   struct ov7670_info *info = to_state(sd);
-   int matrix[CMATRIX_LEN];
-   int ret;
-
-   if (value < -180 || value > 180)
-   return -EINVAL;
-   info->hue = value;
-   ov7670_calc_cmatrix(info, matrix);
-   ret = ov7670_store_cmatrix(sd, matrix);
-   return ret;
-}
-
-
-static int ov7670_g_hue(struct v4l2_subdev *sd, __s32 *value)
-{
-   struct ov7670_info *info = to_state(sd);
-
-   *value = info->hue;
-   return 0;
-}
-
 
 /*
  * Some weird registers seem to store values in a sign/magnitude format!
  */
-static unsigned char ov7670_sm_to_abs(unsigned char v)
-{
-   if ((v & 0x80) == 0)
-   return v + 128;
-   return 128 - (v & 0x7f);
-}
-
 
 static unsigned char ov7670_abs_to_sm(unsigned char v)
 {
@@ -1299,40 +1280,11 @@ static int ov7670_s_brightness(struct v4l2_subdev *sd, 
int value)
return ret;
 }
 
-static int ov7670_g_brightness(struct v4l2_subdev *sd, __s32 *value)
-{
-   unsigned char v = 0;
-   int ret = ov7670_read(sd, REG_BRIGHT, &v);
-
-   *value = ov7670_sm_to_abs(v);
-   return ret;
-}
-
 static int ov7670_s_contrast(struct v4l2_subdev *sd, int value)
 {
return ov7670_write(sd, REG_CONTRAS, (unsigned char) value);
 }
 
-static int ov7670_

[PATCH v2 0/4] ov7670: migrate this sensor and its users to ctrl framework.

2012-09-28 Thread Javier Martin
The following series migrate ov7670 sensor and current users to ctrl framework
as  discussed in [1]. This has been tested against mx2_camera soc-camera bridge,
so tests or acks will be required from people using cam-core and via-camera out
there.

This will have to be applied on top of my previous series:

[PATCH v2 0/5] media: ov7670: driver cleanup and support for ov7674.


All submitted patches have been obtained from Hans' tree and slightly modified
to apply on current media_tree for-v3.7 branch:

http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/cafe-ctrl

Changes since v1:
 - A 4th patch has been added as requested by Hans.
 - See changelog in patch 1.

[PATCH v2 1/4] ov7670: use the control framework
[PATCH v2 2/4] mcam-core: implement the control framework.
[PATCH v2 3/4] via-camera: implement the control framework.
[PATCH v2 4/4] ov7670: remove legacy ctrl callbacks.

[1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg51778.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: [GIT PULL FOR v3.7] all the rest patches!

2012-09-28 Thread Antti Palosaari
PULL request updated, contains now 3 fc2580 driver fixes from  Gianluca 
Gennari. Could you handle these quickly :)


The following changes since commit 8928b6d1568eb9104cc9e2e6627d7086437b2fb3:

  [media] media: mx2_camera: use managed functions to clean up code 
(2012-09-27 15:56:47 -0300)


are available in the git repository at:

  git://linuxtv.org/anttip/media_tree.git for_v3.7_mauro-3

for you to fetch changes up to 5c3cc06e4922d2d6a050948181a8601281227c66:

  fc2580: use macro for 64 bit division and reminder (2012-09-28 
13:18:56 +0300)



Antti Palosaari (4):
  em28xx: implement FE set_lna() callback
  cxd2820r: use static GPIO config when GPIOLIB is undefined
  em28xx: do not set PCTV 290e LNA handler if fe attach fail
  em28xx: PCTV 520e workaround for DRX-K fw loading

Gianluca Gennari (3):
  fc2580: define const as UL to silence a warning
  fc2580: silence uninitialized variable warning
  fc2580: use macro for 64 bit division and reminder

 drivers/media/dvb-frontends/cxd2820r_core.c | 29 
-

 drivers/media/tuners/fc2580.c   |  7 +++
 drivers/media/usb/em28xx/em28xx-dvb.c   | 61 
++---

 3 files changed, 73 insertions(+), 24 deletions(-)


On 09/28/2012 01:15 AM, Antti Palosaari wrote:

Mauro,
New attempt. I really want that "PCTV 520e workaround for DRX-K fw
loading" in too or find out other fix quickly. I have answered too many
bug reports according to it currently. Will take debugs now...

regards
Antti


The following changes since commit
8928b6d1568eb9104cc9e2e6627d7086437b2fb3:

   [media] media: mx2_camera: use managed functions to clean up code
(2012-09-27 15:56:47 -0300)

are available in the git repository at:

   git://linuxtv.org/anttip/media_tree.git for_v3.7_mauro-2

for you to fetch changes up to 2baf1e9dd547402b8a5748e66f894af9c6a2789a:

   em28xx: PCTV 520e workaround for DRX-K fw loading (2012-09-28
01:06:38 +0300)


Antti Palosaari (4):
   em28xx: implement FE set_lna() callback
   cxd2820r: use static GPIO config when GPIOLIB is undefined
   em28xx: do not set PCTV 290e LNA handler if fe attach fail
   em28xx: PCTV 520e workaround for DRX-K fw loading

  drivers/media/dvb-frontends/cxd2820r_core.c | 29
-
  drivers/media/usb/em28xx/em28xx-dvb.c   | 61
++---
  2 files changed, 70 insertions(+), 20 deletions(-)





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


[PATCH v7 5/6] [media] s5p-mfc: MFCv6 register definitions

2012-09-28 Thread Arun Kumar K
From: Jeongtae Park 

Adds register definitions for MFC v6.x firmware

Signed-off-by: Jeongtae Park 
Signed-off-by: Janghyuck Kim 
Signed-off-by: Jaeryul Oh 
Signed-off-by: Naveen Krishna Chatradhi 
Signed-off-by: Arun Kumar K 
---
 drivers/media/platform/s5p-mfc/regs-mfc-v6.h |  408 ++
 1 files changed, 408 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/platform/s5p-mfc/regs-mfc-v6.h

diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v6.h 
b/drivers/media/platform/s5p-mfc/regs-mfc-v6.h
new file mode 100644
index 000..cce1841
--- /dev/null
+++ b/drivers/media/platform/s5p-mfc/regs-mfc-v6.h
@@ -0,0 +1,408 @@
+/*
+ * Register definition file for Samsung MFC V6.x Interface (FIMV) driver
+ *
+ * Copyright (c) 2012 Samsung Electronics
+ * http://www.samsung.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef _REGS_FIMV_V6_H
+#define _REGS_FIMV_V6_H
+
+#define S5P_FIMV_REG_SIZE_V6   (S5P_FIMV_END_ADDR - S5P_FIMV_START_ADDR)
+#define S5P_FIMV_REG_COUNT_V6  ((S5P_FIMV_END_ADDR - S5P_FIMV_START_ADDR) / 4)
+
+/* Number of bits that the buffer address should be shifted for particular
+ * MFC buffers.  */
+#define S5P_FIMV_MEM_OFFSET_V6 0
+
+#define S5P_FIMV_START_ADDR_V6 0x
+#define S5P_FIMV_END_ADDR_V6   0xfd80
+
+#define S5P_FIMV_REG_CLEAR_BEGIN_V60xf000
+#define S5P_FIMV_REG_CLEAR_COUNT_V61024
+
+/* Codec Common Registers */
+#define S5P_FIMV_RISC_ON_V60x
+#define S5P_FIMV_RISC2HOST_INT_V6  0x003C
+#define S5P_FIMV_HOST2RISC_INT_V6  0x0044
+#define S5P_FIMV_RISC_BASE_ADDRESS_V6  0x0054
+
+#define S5P_FIMV_MFC_RESET_V6  0x1070
+
+#define S5P_FIMV_HOST2RISC_CMD_V6  0x1100
+#define S5P_FIMV_H2R_CMD_EMPTY_V6  0
+#define S5P_FIMV_H2R_CMD_SYS_INIT_V6   1
+#define S5P_FIMV_H2R_CMD_OPEN_INSTANCE_V6  2
+#define S5P_FIMV_CH_SEQ_HEADER_V6  3
+#define S5P_FIMV_CH_INIT_BUFS_V6   4
+#define S5P_FIMV_CH_FRAME_START_V6 5
+#define S5P_FIMV_H2R_CMD_CLOSE_INSTANCE_V6 6
+#define S5P_FIMV_H2R_CMD_SLEEP_V6  7
+#define S5P_FIMV_H2R_CMD_WAKEUP_V6 8
+#define S5P_FIMV_CH_LAST_FRAME_V6  9
+#define S5P_FIMV_H2R_CMD_FLUSH_V6  10
+/* RMVME: REALLOC used? */
+#define S5P_FIMV_CH_FRAME_START_REALLOC_V6 5
+
+#define S5P_FIMV_RISC2HOST_CMD_V6  0x1104
+#define S5P_FIMV_R2H_CMD_EMPTY_V6  0
+#define S5P_FIMV_R2H_CMD_SYS_INIT_RET_V6   1
+#define S5P_FIMV_R2H_CMD_OPEN_INSTANCE_RET_V6  2
+#define S5P_FIMV_R2H_CMD_SEQ_DONE_RET_V6   3
+#define S5P_FIMV_R2H_CMD_INIT_BUFFERS_RET_V6   4
+
+#define S5P_FIMV_R2H_CMD_CLOSE_INSTANCE_RET_V6 6
+#define S5P_FIMV_R2H_CMD_SLEEP_RET_V6  7
+#define S5P_FIMV_R2H_CMD_WAKEUP_RET_V6 8
+#define S5P_FIMV_R2H_CMD_COMPLETE_SEQ_RET_V6   9
+#define S5P_FIMV_R2H_CMD_DPB_FLUSH_RET_V6  10
+#define S5P_FIMV_R2H_CMD_NAL_ABORT_RET_V6  11
+#define S5P_FIMV_R2H_CMD_FW_STATUS_RET_V6  12
+#define S5P_FIMV_R2H_CMD_FRAME_DONE_RET_V6 13
+#define S5P_FIMV_R2H_CMD_FIELD_DONE_RET_V6 14
+#define S5P_FIMV_R2H_CMD_SLICE_DONE_RET_V6 15
+#define S5P_FIMV_R2H_CMD_ENC_BUFFER_FUL_RET_V6 16
+#define S5P_FIMV_R2H_CMD_ERR_RET_V632
+
+#define S5P_FIMV_FW_VERSION_V6 0xF000
+
+#define S5P_FIMV_INSTANCE_ID_V60xF008
+#define S5P_FIMV_CODEC_TYPE_V6 0xF00C
+#define S5P_FIMV_CONTEXT_MEM_ADDR_V6   0xF014
+#define S5P_FIMV_CONTEXT_MEM_SIZE_V6   0xF018
+#define S5P_FIMV_PIXEL_FORMAT_V6   0xF020
+
+#define S5P_FIMV_METADATA_ENABLE_V60xF024
+#define S5P_FIMV_DBG_BUFFER_ADDR_V60xF030
+#define S5P_FIMV_DBG_BUFFER_SIZE_V60xF034
+#define S5P_FIMV_RET_INSTANCE_ID_V60xF070
+
+#define S5P_FIMV_ERROR_CODE_V6 0xF074
+#define S5P_FIMV_ERR_WARNINGS_START_V6 160
+#define S5P_FIMV_ERR_DEC_MASK_V6   0x
+#define S5P_FIMV_ERR_DEC_SHIFT_V6  0
+#define S5P_FIMV_ERR_DSPL_MASK_V6  0x
+#define S5P_FIMV_ERR_DSPL_SHIFT_V6 16
+
+#define S5P_FIMV_DBG_BUFFER_OUTPUT_SIZE_V6 0xF078
+#define S5P_FIMV_METADATA_STATUS_V60xF07C
+#define S5P_FIMV_METADATA_ADDR_MB_INFO_V6  0xF080
+#define S5P_FIMV_METADATA_SIZE_MB_INFO_V6  0xF084
+
+/* Decoder Registers */
+#define S5P_FIMV_D_CRC_CTRL_V6 0xF0B0
+#define S5P_FIMV_D_DEC_OPTIONS_V6  0xF0B4
+#define S5P_FIMV_D_OPT_FMO_ASO_CTRL_MASK_V64
+#define S5P_FIMV_D_OPT_DDELAY_EN_SHIFT_V6  3
+#define S5P_FIMV_D_OPT_LF_CTRL_SHIFT_V61
+#define S5P_FIMV_D_OPT_LF_CTRL_MASK_V6 0x3
+#define S5P_FIMV_D_OPT_TILE_MODE_SHIFT_V6  0
+
+#define S5P

[PATCH v7 4/6] [media] s5p-mfc: Add MFC variant data to device context

2012-09-28 Thread Arun Kumar K
MFC variant data replaces various macros used in the driver
which will change in a different version of MFC hardware.
Also does a cleanup of MFC context structure and common files.

Signed-off-by: Jeongtae Park 
Signed-off-by: Janghyuck Kim 
Signed-off-by: Jaeryul Oh 
Signed-off-by: Naveen Krishna Chatradhi 
Signed-off-by: Arun Kumar K 
---
 drivers/media/platform/s5p-mfc/regs-mfc.h   |   17 ++
 drivers/media/platform/s5p-mfc/s5p_mfc.c|   78 +
 drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v5.c |4 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_common.h |   85 ++
 drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c   |7 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_enc.c|   44 +
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c |  213 +++
 7 files changed, 263 insertions(+), 185 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/regs-mfc.h 
b/drivers/media/platform/s5p-mfc/regs-mfc.h
index a19bece..3e2fce0 100644
--- a/drivers/media/platform/s5p-mfc/regs-mfc.h
+++ b/drivers/media/platform/s5p-mfc/regs-mfc.h
@@ -414,5 +414,22 @@
 #define S5P_FIMV_SHARED_EXTENDED_SAR   0x0078
 #define S5P_FIMV_SHARED_H264_I_PERIOD  0x009C
 #define S5P_FIMV_SHARED_RC_CONTROL_CONFIG  0x00A0
+#define S5P_FIMV_SHARED_DISP_FRAME_TYPE_SHIFT  2
+
+/* Offset used by the hardware to store addresses */
+#define MFC_OFFSET_SHIFT   11
+
+#define FIRMWARE_ALIGN 0x2 /* 128KB */
+#define MFC_H264_CTX_BUF_SIZE  0x96000 /* 600KB per H264 instance */
+#define MFC_CTX_BUF_SIZE   0x2800  /* 10KB per instance */
+#define DESC_BUF_SIZE  0x2 /* 128KB for DESC buffer */
+#define SHARED_BUF_SIZE0x2000  /* 8KB for shared 
buffer */
+
+#define DEF_CPB_SIZE   0x4 /* 512KB */
+#define MAX_CPB_SIZE   0x40/* 4MB */
+#define MAX_FW_SIZE0x6
+
+#define MFC_VERSION0x51
+#define MFC_NUM_PORTS  2
 
 #endif /* _REGS_FIMV_H */
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 3319410..a8299ce 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -436,7 +436,6 @@ static void s5p_mfc_handle_seq_done(struct s5p_mfc_ctx *ctx,
 unsigned int reason, unsigned int err)
 {
struct s5p_mfc_dev *dev;
-   unsigned int guard_width, guard_height;
 
if (ctx == NULL)
return;
@@ -450,40 +449,8 @@ static void s5p_mfc_handle_seq_done(struct s5p_mfc_ctx 
*ctx,
ctx->img_height = s5p_mfc_hw_call(dev->mfc_ops, get_img_height,
dev);
 
-   ctx->buf_width = ALIGN(ctx->img_width,
-   S5P_FIMV_NV12MT_HALIGN);
-   ctx->buf_height = ALIGN(ctx->img_height,
-   S5P_FIMV_NV12MT_VALIGN);
-   mfc_debug(2, "SEQ Done: Movie dimensions %dx%d, "
-   "buffer dimensions: %dx%d\n", ctx->img_width,
-   ctx->img_height, ctx->buf_width,
-   ctx->buf_height);
-   if (ctx->codec_mode == S5P_FIMV_CODEC_H264_DEC) {
-   ctx->luma_size = ALIGN(ctx->buf_width *
-   ctx->buf_height, S5P_FIMV_DEC_BUF_ALIGN);
-   ctx->chroma_size = ALIGN(ctx->buf_width *
-ALIGN((ctx->img_height >> 1),
-  S5P_FIMV_NV12MT_VALIGN),
-  S5P_FIMV_DEC_BUF_ALIGN);
-   ctx->mv_size = ALIGN(ctx->buf_width *
-   ALIGN((ctx->buf_height >> 2),
-   S5P_FIMV_NV12MT_VALIGN),
-   S5P_FIMV_DEC_BUF_ALIGN);
-   } else {
-   guard_width = ALIGN(ctx->img_width + 24,
-   S5P_FIMV_NV12MT_HALIGN);
-   guard_height = ALIGN(ctx->img_height + 16,
-   S5P_FIMV_NV12MT_VALIGN);
-   ctx->luma_size = ALIGN(guard_width *
-   guard_height, S5P_FIMV_DEC_BUF_ALIGN);
-   guard_width = ALIGN(ctx->img_width + 16,
-   S5P_FIMV_NV12MT_HALIGN);
-   guard_height = ALIGN((ctx->img_height >> 1) + 4,
-   S5P_FIMV_NV12MT_VALIGN);
-   ctx->chroma_size = ALIGN(guard_width *
-   guard_height, S5P_FIMV_DEC_BUF_ALIGN);
-   ctx->mv_size = 0;
-   }
+   s5p_mfc_hw_call(dev->mfc_ops, dec_calc_dpb_size, ctx);

[PATCH v7 2/6] [media] v4l: Add control definitions for new H264 encoder features

2012-09-28 Thread Arun Kumar K
New controls are added for supporting H264 encoding features like
- MVC frame packing
- Flexible macroblock ordering
- Arbitrary slice ordering
- Hierarchial coding

Signed-off-by: Jeongtae Park 
Signed-off-by: Naveen Krishna Chatradhi 
Signed-off-by: Arun Kumar K 
---
 Documentation/DocBook/media/v4l/controls.xml |  268 +-
 drivers/media/v4l2-core/v4l2-ctrls.c |   42 
 include/linux/v4l2-controls.h|   41 
 3 files changed, 350 insertions(+), 1 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/controls.xml 
b/Documentation/DocBook/media/v4l/controls.xml
index 272a5f7..ce2cfd3 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -1586,7 +1586,6 @@ frame counter of the frame that is currently displayed 
(decoded). This value is
 the decoder is started.
  
 
-
  
  
V4L2_CID_MPEG_VIDEO_DECODER_SLICE_INTERFACE 
@@ -2270,6 +2269,14 @@ Applicable to the MPEG1, MPEG2, MPEG4 encoders.
  
 
  
+ 
+   V4L2_CID_MPEG_VIDEO_VBV_DELAY 
+   integer
+ Sets the initial delay in 
milliseconds for
+VBV buffer control.
+ 
+
+ 
  
V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE 
integer
@@ -2334,6 +2341,265 @@ Applicable to the MPEG4 decoder.
  vop_time_increment value for 
MPEG4. Applicable to the MPEG4 encoder.
  
 
+ 
+ 
+   V4L2_CID_MPEG_VIDEO_H264_SEI_FRAME_PACKING 
+   boolean
+ 
+ Enable generation of frame packing 
supplemental enhancement information in the encoded bitstream.
+The frame packing SEI message contains the arrangement of L and R planes for 
3D viewing. Applicable to the H264 encoder.
+ 
+
+ 
+ 
+   V4L2_CID_MPEG_VIDEO_H264_SEI_FP_CURRENT_FRAME_0 
+   boolean
+ 
+ Sets current frame as frame0 in 
frame packing SEI.
+Applicable to the H264 encoder.
+ 
+
+ 
+ 
+   V4L2_CID_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE 
+   
enum v4l2_mpeg_video_h264_sei_fp_arrangement_type
+ 
+ Frame packing arrangement type for 
H264 SEI.
+Applicable to the H264 encoder.
+Possible values are:
+ 
+ 
+   
+ 
+   
+ 
V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_CHEKERBOARD 
+ Pixels are alternatively from L and R.
+   
+   
+ 
V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_COLUMN 
+ L and R are interlaced by column.
+   
+   
+ 
V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_ROW 
+ L and R are interlaced by row.
+   
+   
+ 
V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_SIDE_BY_SIDE 
+ L is on the left, R on the right.
+   
+   
+ 
V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_TOP_BOTTOM 
+ L is on top, R on bottom.
+   
+   
+ 
V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_TEMPORAL 
+ One view per frame.
+   
+ 
+   
+ 
+
+ 
+ 
+   V4L2_CID_MPEG_VIDEO_H264_FMO 
+   boolean
+ 
+ Enables flexible macroblock ordering 
in the encoded bitstream. It is a technique
+used for restructuring the ordering of macroblocks in pictures. Applicable to 
the H264 encoder.
+ 
+
+ 
+ 
+   V4L2_CID_MPEG_VIDEO_H264_FMO_MAP_TYPE 
+   enum v4l2_mpeg_video_h264_fmo_map_type
+ 
+ When using FMO, the map type divides 
the image in different scan patterns of macroblocks.
+Applicable to the H264 encoder.
+Possible values are:
+ 
+ 
+   
+ 
+   
+ 
V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_INTERLEAVED_SLICES 
+ Slices are interleaved one after other with 
macroblocks in run length order.
+   
+   
+ 
V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_SCATTERED_SLICES 
+ Scatters the macroblocks based on a mathematical 
function known to both encoder and decoder.
+   
+   
+ 
V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_FOREGROUND_WITH_LEFT_OVER 
+ Macroblocks arranged in rectangular areas or 
regions of interest.
+   

[PATCH v7 1/6] [media] v4l: Add fourcc definitions for new formats

2012-09-28 Thread Arun Kumar K
Adds the following new fourcc definitions.
For multiplanar YCbCr
- V4L2_PIX_FMT_NV21M
- V4L2_PIX_FMT_NV12MT_16X16
and compressed formats
- V4L2_PIX_FMT_H264_MVC
- V4L2_PIX_FMT_VP8

Signed-off-by: Jeongtae Park 
Signed-off-by: Naveen Krishna Chatradhi 
Signed-off-by: Arun Kumar K 
---
 Documentation/DocBook/media/v4l/pixfmt-nv12m.xml |   17 -
 Documentation/DocBook/media/v4l/pixfmt.xml   |   10 ++
 include/linux/videodev2.h|4 
 3 files changed, 26 insertions(+), 5 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml 
b/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml
index 5274c24..a990b34 100644
--- a/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml
@@ -1,11 +1,13 @@
-
+
   
-   V4L2_PIX_FMT_NV12M ('NM12')
+   V4L2_PIX_FMT_NV12M ('NM12'), V4L2_PIX_FMT_NV21M 
('NM21'), V4L2_PIX_FMT_NV12MT_16X16
&manvol;
   
   
-V4L2_PIX_FMT_NV12M
-   Variation of V4L2_PIX_FMT_NV12 with 
planes
+   V4L2_PIX_FMT_NV12M
+   V4L2_PIX_FMT_NV21M
+   V4L2_PIX_FMT_NV12MT_16X16
+   Variation of V4L2_PIX_FMT_NV12 and 
V4L2_PIX_FMT_NV21 with planes
  non contiguous in memory. 
   
   
@@ -22,7 +24,12 @@ The CbCr plane is the same width, in bytes, as the Y plane 
(and of the image),
 but is half as tall in pixels. Each CbCr pair belongs to four pixels. For 
example,
 Cb0/Cr0 belongs to
 Y'00, Y'01,
-Y'10, Y'11. 
+Y'10, Y'11.
+V4L2_PIX_FMT_NV12MT_16X16 is the tiled version of
+V4L2_PIX_FMT_NV12M with 16x16 macroblock tiles. Here 
pixels
+are arranged in 16x16 2D tiles and tiles are arranged in linear order in 
memory.
+V4L2_PIX_FMT_NV21M is the same as 
V4L2_PIX_FMT_NV12M
+except the Cb and Cr bytes are swapped, the CrCb plane starts with a Cr 
byte.
 
V4L2_PIX_FMT_NV12M is intended to be
 used only in drivers and applications that support the multi-planar API,
diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml 
b/Documentation/DocBook/media/v4l/pixfmt.xml
index 1ddbfab..6ca0be4 100644
--- a/Documentation/DocBook/media/v4l/pixfmt.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt.xml
@@ -758,6 +758,11 @@ extended control 
V4L2_CID_MPEG_STREAM_TYPE, see
'AVC1'
H264 video elementary stream without start codes.
  
+ 
+   V4L2_PIX_FMT_H264_MVC
+   'MVC'
+   H264 MVC video elementary stream.
+ 
  
V4L2_PIX_FMT_H263
'H263'
@@ -793,6 +798,11 @@ extended control 
V4L2_CID_MPEG_STREAM_TYPE, see
'VC1L'
VC1, SMPTE 421M Annex L compliant stream.
  
+ 
+   V4L2_PIX_FMT_VP8
+   'VP8'
+   VP8 video elementary stream.
+ 

   
 
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 61395ef..16e6ab0 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -366,7 +366,9 @@ struct v4l2_pix_format {
 
 /* two non contiguous planes - one Y, one Cr + Cb interleaved  */
 #define V4L2_PIX_FMT_NV12M   v4l2_fourcc('N', 'M', '1', '2') /* 12  Y/CbCr 
4:2:0  */
+#define V4L2_PIX_FMT_NV21M   v4l2_fourcc('N', 'M', '2', '1') /* 21  Y/CrCb 
4:2:0  */
 #define V4L2_PIX_FMT_NV12MT  v4l2_fourcc('T', 'M', '1', '2') /* 12  Y/CbCr 
4:2:0 64x32 macroblocks */
+#define V4L2_PIX_FMT_NV12MT_16X16 v4l2_fourcc('V', 'M', '1', '2') /* 12  
Y/CbCr 4:2:0 16x16 macroblocks */
 
 /* three non contiguous planes - Y, Cb, Cr */
 #define V4L2_PIX_FMT_YUV420M v4l2_fourcc('Y', 'M', '1', '2') /* 12  YUV420 
planar */
@@ -403,6 +405,7 @@ struct v4l2_pix_format {
 #define V4L2_PIX_FMT_MPEG v4l2_fourcc('M', 'P', 'E', 'G') /* MPEG-1/2/4 
Multiplexed */
 #define V4L2_PIX_FMT_H264 v4l2_fourcc('H', '2', '6', '4') /* H264 with 
start codes */
 #define V4L2_PIX_FMT_H264_NO_SC v4l2_fourcc('A', 'V', 'C', '1') /* H264 
without start codes */
+#define V4L2_PIX_FMT_H264_MVC v4l2_fourcc('M', '2', '6', '4') /* H264 MVC */
 #define V4L2_PIX_FMT_H263 v4l2_fourcc('H', '2', '6', '3') /* H263  
*/
 #define V4L2_PIX_FMT_MPEG1v4l2_fourcc('M', 'P', 'G', '1') /* MPEG-1 ES 
*/
 #define V4L2_PIX_FMT_MPEG2v4l2_fourcc('M', 'P', 'G', '2') /* MPEG-2 ES 
*/
@@ -410,6 +413,7 @@ struct v4l2_pix_format {
 #define V4L2_PIX_FMT_XVID v4l2_fourcc('X', 'V', 'I', 'D') /* Xvid  
 */
 #define V4L2_PIX_FMT_VC1_ANNEX_G v4l2_fourcc('V', 'C', '1', 'G') /* SMPTE 421M 
Annex G compliant stream */
 #define V4L2_PIX_FMT_VC1_ANNEX_L v4l2_fourcc('V', 'C', '1', 'L') /* SMPTE 421M 
Annex L compliant stream */
+#define V4L2_PIX_FMT_VP8  v4l2_fourcc('V', 'P', '8', '0') /* VP8 */
 
 /*  Vendor-specific formats   */
 #define V4L2_PIX_FMT_CPIA1v4l2_fourcc('C', 'P', 'I', 'A') /* cpia1 YUV */
-- 
1.7.0.4

--
To unsubscribe from this list: send the line "unsubscribe linux-me

[PATCH v7 0/6] Update MFC v4l2 driver to support MFC6.x

2012-09-28 Thread Arun Kumar K
The patchset adds support for MFCv6 firmware in s5p-mfc driver.
The patches are rebased to the latest media-tree.

Changelog v7
- Removed unused macros from register files

Changelog v6
- Use s5p_mfc_hw_call macro to call all HW related ops and cmds
- Rebased onto latest media-tree
- Resending patches adding required v4l controls
- Addressed review comments of Patch v5

Changelog v5
- Modified ops mechanism for macro based function call
- Addressed all other review comments on Patch v4

Changelog v4
- Separate patch for callback based architecture.
- Patches divided to enable incremental compilation.
- Working MFCv6 encoder and decoder.
- Addressed review comments given for v3 patchset.

Changelog v3
- Supports MFCv5 and v6 co-existence.
- Tested for encoding & decoding in MFCv5.
- Supports only decoding in MFCv6 now.
- Can be compiled with kernel image and as module.
- Config macros for MFC version selection removed.
- All previous review comments addressed.

Changelog v2
- Addressed review comments received
http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/45189

Changelog v1
- Fixed crash issue in Exynos4 SoCs running MFC 5.1
- Encoder not tested

Arun Kumar K (4):
  [media] v4l: Add fourcc definitions for new formats
  [media] v4l: Add control definitions for new H264 encoder features
  [media] s5p-mfc: Update MFCv5 driver for callback based architecture
  [media] s5p-mfc: Add MFC variant data to device context

Jeongtae Park (2):
  [media] s5p-mfc: MFCv6 register definitions
  [media] s5p-mfc: Update MFC v4l2 driver to support MFC6.x

 Documentation/DocBook/media/v4l/controls.xml |  268 +++-
 Documentation/DocBook/media/v4l/pixfmt-nv12m.xml |   17 +-
 Documentation/DocBook/media/v4l/pixfmt.xml   |   10 +
 drivers/media/platform/Kconfig   |4 +-
 drivers/media/platform/s5p-mfc/Makefile  |7 +-
 drivers/media/platform/s5p-mfc/regs-mfc-v6.h |  408 +
 drivers/media/platform/s5p-mfc/regs-mfc.h|   38 +
 drivers/media/platform/s5p-mfc/s5p_mfc.c |  296 +++--
 drivers/media/platform/s5p-mfc/s5p_mfc_cmd.c |  109 +--
 drivers/media/platform/s5p-mfc/s5p_mfc_cmd.h |   15 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v5.c  |  166 ++
 drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v5.h  |   20 +
 drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c  |  156 ++
 drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.h  |   20 +
 drivers/media/platform/s5p-mfc/s5p_mfc_common.h  |  191 ++-
 drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c|  194 ++-
 drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.h|1 +
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c |  258 ++-
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.h |1 +
 drivers/media/platform/s5p-mfc/s5p_mfc_enc.c |  239 ++--
 drivers/media/platform/s5p-mfc/s5p_mfc_enc.h |1 +
 drivers/media/platform/s5p-mfc/s5p_mfc_intr.c|   11 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_opr.c | 1386 +---
 drivers/media/platform/s5p-mfc/s5p_mfc_opr.h |  133 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c  | 1763 +++
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.h  |   85 +
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c  | 1956 ++
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h  |   50 +
 drivers/media/platform/s5p-mfc/s5p_mfc_pm.c  |3 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_shm.c |   47 -
 drivers/media/platform/s5p-mfc/s5p_mfc_shm.h |   90 -
 drivers/media/v4l2-core/v4l2-ctrls.c |   42 +
 include/linux/v4l2-controls.h|   41 +
 include/linux/videodev2.h|4 +
 34 files changed, 5937 insertions(+), 2093 deletions(-)
 create mode 100644 drivers/media/platform/s5p-mfc/regs-mfc-v6.h
 create mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v5.c
 create mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v5.h
 create mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c
 create mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.h
 create mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c
 create mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.h
 create mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
 create mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h
 delete mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_shm.c
 delete mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_shm.h

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


[PATCH v3] drivers/media: Remove unnecessary semicolon

2012-09-28 Thread Peter Senna Tschudin
A simplified version of the semantic patch that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// 
@r1@
statement S;
position p,p1;
@@
S@p1;@p

@script:python r2@
p << r1.p;
p1 << r1.p1;
@@
if p[0].line != p1[0].line_end:
cocci.include_match(False)
@@
position r1.p;
@@
-;@p
// 

Signed-off-by: Peter Senna Tschudin 
---
Changes from v2:
Include semantic patch in the commit message.

The full version of the semantic patch can be found at:
http://comments.gmane.org/gmane.comp.version-control.coccinelle/2724

 drivers/media/dvb-core/dvb_frontend.c |  2 +-
 drivers/media/dvb-frontends/a8293.c   |  2 +-
 drivers/media/dvb-frontends/af9013.c  |  6 +++---
 drivers/media/dvb-frontends/bcm3510.c |  2 +-
 drivers/media/dvb-frontends/cx24110.c |  6 +++---
 drivers/media/dvb-frontends/drxd_hard.c   |  2 +-
 drivers/media/dvb-frontends/isl6405.c |  2 +-
 drivers/media/dvb-frontends/isl6421.c |  2 +-
 drivers/media/dvb-frontends/itd1000.c |  2 +-
 drivers/media/dvb-frontends/lnbp21.c  |  4 ++--
 drivers/media/dvb-frontends/lnbp22.c  |  2 +-
 drivers/media/dvb-frontends/si21xx.c  |  4 ++--
 drivers/media/dvb-frontends/sp8870.c  |  6 +++---
 drivers/media/dvb-frontends/sp887x.c  |  6 +++---
 drivers/media/dvb-frontends/stv0299.c |  6 +++---
 drivers/media/dvb-frontends/stv0900_core.c|  4 ++--
 drivers/media/dvb-frontends/tda8083.c |  4 ++--
 drivers/media/i2c/cx25840/cx25840-core.c  |  2 +-
 drivers/media/pci/bt8xx/dst_ca.c  |  2 +-
 drivers/media/pci/cx23885/altera-ci.c |  4 ++--
 drivers/media/pci/cx23885/cimax2.c|  2 +-
 drivers/media/pci/cx88/cx88-blackbird.c   |  6 +++---
 drivers/media/pci/cx88/cx88-dvb.c |  2 +-
 drivers/media/pci/cx88/cx88-mpeg.c|  2 +-
 drivers/media/pci/cx88/cx88-tvaudio.c |  4 ++--
 drivers/media/pci/cx88/cx88-video.c   |  2 +-
 drivers/media/pci/saa7134/saa7134-video.c |  2 +-
 drivers/media/platform/exynos-gsc/gsc-regs.c  |  4 ++--
 drivers/media/radio/si470x/radio-si470x-i2c.c |  2 +-
 drivers/media/radio/si470x/radio-si470x-usb.c |  2 +-
 drivers/media/radio/si4713-i2c.c  | 12 ++--
 drivers/media/usb/dvb-usb-v2/af9015.c |  4 ++--
 drivers/media/usb/dvb-usb-v2/af9035.c |  2 +-
 33 files changed, 58 insertions(+), 58 deletions(-)

diff --git a/drivers/media/dvb-core/dvb_frontend.c 
b/drivers/media/dvb-core/dvb_frontend.c
index 479a5e5..b5f141a 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -2288,7 +2288,7 @@ static int dvb_frontend_ioctl_legacy(struct file *file,
fepriv->tune_mode_flags = (unsigned long) parg;
err = 0;
break;
-   };
+   }
 
return err;
 }
diff --git a/drivers/media/dvb-frontends/a8293.c 
b/drivers/media/dvb-frontends/a8293.c
index cff44a3..74fbb5d 100644
--- a/drivers/media/dvb-frontends/a8293.c
+++ b/drivers/media/dvb-frontends/a8293.c
@@ -90,7 +90,7 @@ static int a8293_set_voltage(struct dvb_frontend *fe,
default:
ret = -EINVAL;
goto err;
-   };
+   }
 
ret = a8293_wr(priv, &priv->reg[0], 1);
if (ret)
diff --git a/drivers/media/dvb-frontends/af9013.c 
b/drivers/media/dvb-frontends/af9013.c
index e9f04a3..a204f28 100644
--- a/drivers/media/dvb-frontends/af9013.c
+++ b/drivers/media/dvb-frontends/af9013.c
@@ -241,7 +241,7 @@ static int af9013_set_gpio(struct af9013_state *state, u8 
gpio, u8 gpioval)
KBUILD_MODNAME, gpio);
ret = -EINVAL;
goto err;
-   };
+   }
 
switch (gpio) {
case 0:
@@ -253,7 +253,7 @@ static int af9013_set_gpio(struct af9013_state *state, u8 
gpio, u8 gpioval)
default:
pos = 4;
break;
-   };
+   }
 
ret = af9013_wr_reg_bits(state, addr, pos, 4, gpioval);
if (ret)
@@ -726,7 +726,7 @@ static int af9013_set_frontend(struct dvb_frontend *fe)
default:
dev_dbg(&state->i2c->dev, "%s: invalid hierarchy\n", __func__);
auto_mode = 1;
-   };
+   }
 
switch (c->modulation) {
case QAM_AUTO:
diff --git a/drivers/media/dvb-frontends/bcm3510.c 
b/drivers/media/dvb-frontends/bcm3510.c
index 033cd7a..1b77909 100644
--- a/drivers/media/dvb-frontends/bcm3510.c
+++ b/drivers/media/dvb-frontends/bcm3510.c
@@ -527,7 +527,7 @@ static int bcm3510_set_frontend(struct dvb_frontend *fe)
cmd.ACQUIRE1.IF_FREQ = 0x0;
default:
return -EINVAL;
-   };
+   }
cmd.ACQUIRE0.OFFSET = 0;
cmd.ACQUIRE0.NTSCSWEEP = 1;
cmd.ACQUIRE0.FA = 1;
diff --git a/drivers/media/dvb-frontends/cx24110.c 
b/drivers/media/dvb-frontends/cx24110.c
index 3180f5b..0cd69

Re: [PATCH] [media] s5p-mfc: Fix misplaced return statement in s5p_mfc_suspend()

2012-09-28 Thread Sylwester Nawrocki
On 09/28/2012 11:21 AM, Kamil Debski wrote:
>> -Original Message-
>> From: Sachin Kamat [mailto:sachin.ka...@linaro.org]
>> Sent: 28 September 2012 09:02
>> To: linux-media@vger.kernel.org
>> Cc: k.deb...@samsung.com; s.nawro...@samsung.com; sachin.ka...@linaro.org;
>> patc...@linaro.org
>> Subject: [PATCH] [media] s5p-mfc: Fix misplaced return statement in
>> s5p_mfc_suspend()
>>
>> return statement was wrongly placed before a code that needs to be
>> executed. Moved the return statement to the end of the function.
>>
>> Tested suspend/resume on SMDK4412 board using 3.5-rc6 kernel.
>>
>> Signed-off-by: Sachin Kamat 
> 
> Acked-by: Kamil Debski 

Applied, thank you.
--
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


[RFCv2 PATCH 2/4] videobuf2-core: fill in length field for multiplanar buffers.

2012-09-28 Thread Hans Verkuil
From: Hans Verkuil 

length should be set to num_planes in __fill_v4l2_buffer(). That way the
caller knows how many planes there are in the buffer.

Signed-off-by: Hans Verkuil 
---
 drivers/media/v4l2-core/videobuf2-core.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index 5a132b2..432df11 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -348,6 +348,7 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb, 
struct v4l2_buffer *b)
 * Fill in plane-related data if userspace provided an array
 * for it. The caller has already verified memory and size.
 */
+   b->length = vb->num_planes;
memcpy(b->m.planes, vb->v4l2_planes,
b->length * sizeof(struct v4l2_plane));
} else {
-- 
1.7.10.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


[RFCv2 PATCH 0/4] vb2 & multiplanar fixes/changes

2012-09-28 Thread Hans Verkuil
Changes since RFCv1:

- Don't move num_planes to vb2_queue. In certain circumstances it is possible
  to have buffers with different number of planes, so keep num_planes in
  vb2_buffer. This complicated vb2_dqbuf a bit since the plane verification
  now has to be done just before the buffer is dequeued from the done_list.
  You don't want to dequeue it if the v4l2_buffer didn't provide enough
  room for all the planes.

This RFC PATCH series is related to this email I sent:

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

I've decided to fix the plane verification problem. This is done in the
first patch. The second patch fills in the length field as I proposed
in the mail above.

The third fixes a bug for PREPARE_BUF in the multiplanar case that I came
across by accident.

The last patch updates the DocBook and clarifies a number of things.

Comments are welcome,

Hans

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


[RFCv2 PATCH 3/4] v4l2-ioctl.c: handle PREPARE_BUF like QUERYBUF.

2012-09-28 Thread Hans Verkuil
From: Hans Verkuil 

The core code for PREPARE_BUF didn't take the multiplanar case into account,
which might cause page faults. Handle PREPARE_BUF just like QUERYBUF and
QBUF/DQBUF.

Signed-off-by: Hans Verkuil 
---
 drivers/media/v4l2-core/v4l2-ioctl.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 09512eb..6ae885d 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -2182,6 +2182,7 @@ static int check_array_args(unsigned int cmd, void *parg, 
size_t *array_size,
int ret = 0;
 
switch (cmd) {
+   case VIDIOC_PREPARE_BUF:
case VIDIOC_QUERYBUF:
case VIDIOC_QBUF:
case VIDIOC_DQBUF: {
-- 
1.7.10.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


[RFCv2 PATCH 1/4] videobuf2-core: move plane verification out of __fill_v4l2/vb_buffer.

2012-09-28 Thread Hans Verkuil
From: Hans Verkuil 

The plane verification should be done before actually queuing or
dequeuing buffers, so move it out of __fill_v4l2_buffer and __fill_vb_buffer
and call it as a separate step.

This also makes it possible to change the return type of __fill_v4l2/vb_buffer
to void.

The dqbuf case took some special care: before removing a buffer from the
done_list you have to verify that the receiving v4l2_buffer has enough room
for all the planes. The number of planes can differ between buffers due to the
fact that buffers for other formats can be prepared using VIDIOC_PREPARE_BUF.

Signed-off-by: Hans Verkuil 
---
 drivers/media/v4l2-core/videobuf2-core.c |   78 +++---
 1 file changed, 38 insertions(+), 40 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index e6a26b4..5a132b2 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -276,6 +276,9 @@ static void __vb2_queue_free(struct vb2_queue *q, unsigned 
int buffers)
  */
 static int __verify_planes_array(struct vb2_buffer *vb, const struct 
v4l2_buffer *b)
 {
+   if (!V4L2_TYPE_IS_MULTIPLANAR(b->type))
+   return 0;
+
/* Is memory for copying plane information present? */
if (NULL == b->m.planes) {
dprintk(1, "Multi-planar buffer passed but "
@@ -331,10 +334,9 @@ static bool __buffers_in_use(struct vb2_queue *q)
  * __fill_v4l2_buffer() - fill in a struct v4l2_buffer with information to be
  * returned to userspace
  */
-static int __fill_v4l2_buffer(struct vb2_buffer *vb, struct v4l2_buffer *b)
+static void __fill_v4l2_buffer(struct vb2_buffer *vb, struct v4l2_buffer *b)
 {
struct vb2_queue *q = vb->vb2_queue;
-   int ret;
 
/* Copy back data such as timestamp, flags, etc. */
memcpy(b, &vb->v4l2_buf, offsetof(struct v4l2_buffer, m));
@@ -342,13 +344,9 @@ static int __fill_v4l2_buffer(struct vb2_buffer *vb, 
struct v4l2_buffer *b)
b->reserved = vb->v4l2_buf.reserved;
 
if (V4L2_TYPE_IS_MULTIPLANAR(q->type)) {
-   ret = __verify_planes_array(vb, b);
-   if (ret)
-   return ret;
-
/*
 * Fill in plane-related data if userspace provided an array
-* for it. The memory and size is verified above.
+* for it. The caller has already verified memory and size.
 */
memcpy(b->m.planes, vb->v4l2_planes,
b->length * sizeof(struct v4l2_plane));
@@ -391,8 +389,6 @@ static int __fill_v4l2_buffer(struct vb2_buffer *vb, struct 
v4l2_buffer *b)
 
if (__buffer_in_use(q, vb))
b->flags |= V4L2_BUF_FLAG_MAPPED;
-
-   return 0;
 }
 
 /**
@@ -411,6 +407,7 @@ static int __fill_v4l2_buffer(struct vb2_buffer *vb, struct 
v4l2_buffer *b)
 int vb2_querybuf(struct vb2_queue *q, struct v4l2_buffer *b)
 {
struct vb2_buffer *vb;
+   int ret;
 
if (b->type != q->type) {
dprintk(1, "querybuf: wrong buffer type\n");
@@ -422,8 +419,10 @@ int vb2_querybuf(struct vb2_queue *q, struct v4l2_buffer 
*b)
return -EINVAL;
}
vb = q->bufs[b->index];
-
-   return __fill_v4l2_buffer(vb, b);
+   ret = __verify_planes_array(vb, b);
+   if (!ret)
+   __fill_v4l2_buffer(vb, b);
+   return ret;
 }
 EXPORT_SYMBOL(vb2_querybuf);
 
@@ -813,24 +812,16 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum 
vb2_buffer_state state)
 EXPORT_SYMBOL_GPL(vb2_buffer_done);
 
 /**
- * __fill_vb2_buffer() - fill a vb2_buffer with information provided in
- * a v4l2_buffer by the userspace
+ * __fill_vb2_buffer() - fill a vb2_buffer with information provided in a
+ * v4l2_buffer by the userspace. The caller has already verified that struct
+ * v4l2_buffer has a valid number of planes.
  */
-static int __fill_vb2_buffer(struct vb2_buffer *vb, const struct v4l2_buffer 
*b,
+static void __fill_vb2_buffer(struct vb2_buffer *vb, const struct v4l2_buffer 
*b,
struct v4l2_plane *v4l2_planes)
 {
unsigned int plane;
-   int ret;
 
if (V4L2_TYPE_IS_MULTIPLANAR(b->type)) {
-   /*
-* Verify that the userspace gave us a valid array for
-* plane information.
-*/
-   ret = __verify_planes_array(vb, b);
-   if (ret)
-   return ret;
-
/* Fill in driver-provided information for OUTPUT types */
if (V4L2_TYPE_IS_OUTPUT(b->type)) {
/*
@@ -872,8 +863,6 @@ static int __fill_vb2_buffer(struct vb2_buffer *vb, const 
struct v4l2_buffer *b,
vb->v4l2_buf.field = b->field;
vb->v4l2_buf.timestamp = b->timestamp;
vb->v4l2_buf.flags = b->flags & ~V4L2_BUFFER_STATE_FLAGS;
-
-   return 0;
 }
 
 /**
@@ -888,10 +877,8

[RFCv2 PATCH 4/4] DocBook: various updates w.r.t. v4l2_buffer and multiplanar.

2012-09-28 Thread Hans Verkuil
From: Hans Verkuil 

Clarify the behavior of v4l2_buffer in the multiplanar case,
including fixing a false statement: you can't set m.planes to NULL
when calling DQBUF.

Signed-off-by: Hans Verkuil 
---
 Documentation/DocBook/media/v4l/io.xml  |6 --
 Documentation/DocBook/media/v4l/vidioc-qbuf.xml |3 +--
 Documentation/DocBook/media/v4l/vidioc-querybuf.xml |   11 +++
 3 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/io.xml 
b/Documentation/DocBook/media/v4l/io.xml
index 97f785a..b5d1cbd 100644
--- a/Documentation/DocBook/media/v4l/io.xml
+++ b/Documentation/DocBook/media/v4l/io.xml
@@ -677,8 +677,10 @@ memory, set by the application. See  for details.
length

Size of the buffer (not the payload) in bytes for the
-   single-planar API. For the multi-planar API should contain the
-   number of elements in the planes array.
+   single-planar API. For the multi-planar API the application sets
+   this to the number of elements in the 
planes
+   array. The driver will fill in the actual number of valid elements 
in
+   that array.

  
  
diff --git a/Documentation/DocBook/media/v4l/vidioc-qbuf.xml 
b/Documentation/DocBook/media/v4l/vidioc-qbuf.xml
index 6a821a6..2d37abe 100644
--- a/Documentation/DocBook/media/v4l/vidioc-qbuf.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-qbuf.xml
@@ -121,8 +121,7 @@ remaining fields or returns an error code. The driver may 
also set
 field. It indicates a non-critical (recoverable) streaming error. In such case
 the application may continue as normal, but should be aware that data in the
 dequeued buffer might be corrupted. When using the multi-planar API, the
-planes array does not have to be passed; the 
m.planes
-member must be set to NULL in that case.
+planes array must be passed in as well.
 
 By default VIDIOC_DQBUF blocks when no
 buffer is in the outgoing queue. When the
diff --git a/Documentation/DocBook/media/v4l/vidioc-querybuf.xml 
b/Documentation/DocBook/media/v4l/vidioc-querybuf.xml
index 6e414d7..a597155 100644
--- a/Documentation/DocBook/media/v4l/vidioc-querybuf.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-querybuf.xml
@@ -48,8 +48,8 @@
   
 Description
 
-This ioctl is part of the memory
-mapping I/O method. It can be used to query the status of a
+This ioctl is part of the streaming
+ I/O method. It can be used to query the status of a
 buffer at any time after buffers have been allocated with the
 &VIDIOC-REQBUFS; ioctl.
 
@@ -71,6 +71,7 @@ the structure.
 
 In the flags field the
 V4L2_BUF_FLAG_MAPPED,
+V4L2_BUF_FLAG_PREPARED,
 V4L2_BUF_FLAG_QUEUED and
 V4L2_BUF_FLAG_DONE flags will be valid. The
 memory field will be set to the current
@@ -79,8 +80,10 @@ contains the offset of the buffer from the start of the 
device memory,
 the length field its size. For the multi-planar API,
 fields m.mem_offset and
 length in the m.planes
-array elements will be used instead. The driver may or may not set the 
remaining
-fields and flags, they are meaningless in this context.
+array elements will be used instead and the length
+field of &v4l2-buffer; is set to the number of filled-in array elements.
+The driver may or may not set the remaining fields and flags, they are
+meaningless in this context.
 
 The v4l2_buffer structure is
 specified in .
-- 
1.7.10.4

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


RE: [PATCH] [media] s5p-mfc: Fix misplaced return statement in s5p_mfc_suspend()

2012-09-28 Thread Kamil Debski
Hi Sachin,

Thank you for your patch, fixing this bug and testing suspend/resume.

Best wishes,
--
Kamil Debski
Linux Platform Group
Samsung Poland R&D Center


> -Original Message-
> From: Sachin Kamat [mailto:sachin.ka...@linaro.org]
> Sent: 28 September 2012 09:02
> To: linux-media@vger.kernel.org
> Cc: k.deb...@samsung.com; s.nawro...@samsung.com; sachin.ka...@linaro.org;
> patc...@linaro.org
> Subject: [PATCH] [media] s5p-mfc: Fix misplaced return statement in
> s5p_mfc_suspend()
> 
> return statement was wrongly placed before a code that needs to be
> executed. Moved the return statement to the end of the function.
> 
> Tested suspend/resume on SMDK4412 board using 3.5-rc6 kernel.
> 
> Signed-off-by: Sachin Kamat 

Acked-by: Kamil Debski 

> ---
>  drivers/media/platform/s5p-mfc/s5p_mfc.c |5 +++--
>  1 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
> b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> index e3e616d..e913a1c 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> @@ -1148,7 +1148,7 @@ static int s5p_mfc_suspend(struct device *dev)
> 
>   if (m_dev->num_inst == 0)
>   return 0;
> - return s5p_mfc_sleep(m_dev);
> +
>   if (test_and_set_bit(0, &m_dev->enter_suspend) != 0) {
>   mfc_err("Error: going to suspend for a second time\n");
>   return -EIO;
> @@ -1167,7 +1167,8 @@ static int s5p_mfc_suspend(struct device *dev)
>   return -EIO;
>   }
>   }
> - return 0;
> +
> + return s5p_mfc_sleep(m_dev);
>  }
> 
>  static int s5p_mfc_resume(struct device *dev)
> --
> 1.7.4.1

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


[PATCH 2/2] V4L: soc_camera: disable I2C subdev streamon for mpc52xx_csi

2012-09-28 Thread Anatolij Gustschin
With mpc52xx_csi interface I2C subdev streamon after vb2_streamon()
doesn't work due to mpc52xx sensor interface glue-logic restrictions.

Since mpc5200 doesn't have a camera sensor interface, the sensor on
O2D cameras is connected to the LocalPlus bus by special glue-logic.
While sensor read-out the sensor will be clocked with the bus chip-
select signal as the sensor clock so that the read-out is synchronous
with the data accesses on the bus. Therefore, I2C access can't be
performed when the glue-logic is setup for sensor read-out.

mpc52xx_csi driver for O2D cameras performs I2C subdev streamon in
its start_streaming() operation and then disables the I2C bus access
by configuring the interface glue-logic for sensor read-out.
For above-mentioned reasons we disable this subdev call here.

Signed-off-by: Anatolij Gustschin 
---
 drivers/media/platform/soc_camera/soc_camera.c |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/media/platform/soc_camera/soc_camera.c 
b/drivers/media/platform/soc_camera/soc_camera.c
index f6b1c1f..64e0abb 100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
@@ -809,7 +809,7 @@ static int soc_camera_streamon(struct file *file, void 
*priv,
 {
struct soc_camera_device *icd = file->private_data;
struct soc_camera_host *ici = to_soc_camera_host(icd->parent);
-   struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
+   struct v4l2_subdev __maybe_unused *sd = soc_camera_to_subdev(icd);
int ret;
 
WARN_ON(priv != file->private_data);
@@ -826,8 +826,11 @@ static int soc_camera_streamon(struct file *file, void 
*priv,
else
ret = vb2_streamon(&icd->vb2_vidq, i);
 
+#if !defined(CONFIG_VIDEO_MPC52xx_CSI) && \
+!defined(CONFIG_VIDEO_MPC52xx_CSI_MODULE)
if (!ret)
v4l2_subdev_call(sd, video, s_stream, 1);
+#endif
 
return ret;
 }
-- 
1.7.1

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


[PATCH 1/2] V4L: soc_camera: add driver for IFM camera sensor interface on mpc5200

2012-09-28 Thread Anatolij Gustschin
IFM O2D cameras use special sensor bus interface glue-logic to
connect camera sensors to mpc5200 LocalPlus bus. Add camera
sensor driver for this mpc5200 camera interface.

Signed-off-by: Anatolij Gustschin 
---
 drivers/media/platform/soc_camera/Kconfig  |7 +
 drivers/media/platform/soc_camera/Makefile |1 +
 .../media/platform/soc_camera/mpc5200-csi-camera.c | 1212 
 3 files changed, 1220 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/platform/soc_camera/mpc5200-csi-camera.c

diff --git a/drivers/media/platform/soc_camera/Kconfig 
b/drivers/media/platform/soc_camera/Kconfig
index 9afe1e7..4d6c74d 100644
--- a/drivers/media/platform/soc_camera/Kconfig
+++ b/drivers/media/platform/soc_camera/Kconfig
@@ -85,3 +85,10 @@ config VIDEO_ATMEL_ISI
  This module makes the ATMEL Image Sensor Interface available
  as a v4l2 device.
 
+config VIDEO_MPC52xx_CSI
+   tristate "IFM MPC5200 Camera Sensor Interface driver"
+   depends on SOC_CAMERA && PPC_MPC52xx
+   select PPC_BESTCOMM_GEN_BD
+   select VIDEOBUF2_DMA_CONTIG
+   ---help---
+ This is a driver for IFM camera sensor interface on mpc5200.
diff --git a/drivers/media/platform/soc_camera/Makefile 
b/drivers/media/platform/soc_camera/Makefile
index 136b7f8..79e6339 100644
--- a/drivers/media/platform/soc_camera/Makefile
+++ b/drivers/media/platform/soc_camera/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_SOC_CAMERA_PLATFORM)   += soc_camera_platform.o
 
 # soc-camera host drivers have to be linked after camera drivers
 obj-$(CONFIG_VIDEO_ATMEL_ISI)  += atmel-isi.o
+obj-$(CONFIG_VIDEO_MPC52xx_CSI)+= mpc5200-csi-camera.o
 obj-$(CONFIG_VIDEO_MX1)+= mx1_camera.o
 obj-$(CONFIG_VIDEO_MX2)+= mx2_camera.o
 obj-$(CONFIG_VIDEO_MX3)+= mx3_camera.o
diff --git a/drivers/media/platform/soc_camera/mpc5200-csi-camera.c 
b/drivers/media/platform/soc_camera/mpc5200-csi-camera.c
new file mode 100644
index 000..84746c1
--- /dev/null
+++ b/drivers/media/platform/soc_camera/mpc5200-csi-camera.c
@@ -0,0 +1,1212 @@
+/*
+ * Driver for image sensor/fpga interface on mpc5200 LPB found
+ * on IFM o2d based boards
+ *
+ * Code base taken from i.MX3x camera host driver
+ * Copyright (C) 2008
+ * Guennadi Liakhovetski, DENX Software Engineering, 
+ *
+ * Copyright (C) 2012
+ * Anatolij Gustschin , DENX Software Engineering
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define O2XXX_CAM_DRV_NAME "o2d_csi"
+
+#define MAX_VIDEO_MEM  2   /* Video memory limit in megabytes */
+
+#define DEFAULT_IMAGE_WIDTH688 /* Default image width */
+#define DEFAULT_IMAGE_HEIGHT   480 /* Default image height */
+#define DEFAULT_IMAGE_LENGTH   (DEFAULT_IMAGE_WIDTH * DEFAULT_IMAGE_HEIGHT)
+
+enum o2xxx_buffer_state {
+   BUF_NEEDS_INIT,
+   BUF_PREPARED,
+};
+
+struct o2xxx_camera_buffer {
+   /* v4l2_buffer must be first */
+   struct vb2_buffer   vb;
+   dma_addr_t  paddr;
+   size_t  bsize;
+   enum o2xxx_buffer_state state;
+   struct list_headqueue;
+};
+
+struct o2d_csi_priv {
+   /* sensor control gpios */
+   int imag_capture;
+   int imag_reset;
+   int imag_master_en;
+
+   struct device_node *gpt_np;
+   struct mpc52xx_gpt __iomem *gpt;
+   struct mpc52xx_intr __iomem *intr;
+   int irq;
+   int chip_select;
+
+   /* LocalPlus Bus camera CS phys addr */
+   resource_size_t lpb_cs_phys;
+
+   resource_size_t lpbfifo_regs_phys;
+   void __iomem *lpbfifo_regs;
+
+   /* soc_camera and v4l2 interface */
+   struct platform_device *soc_cam_pdev;
+   struct soc_camera_device *icd;
+   struct soc_camera_host soc_host;
+   size_t buf_total;
+   int sequence;
+   struct vb2_alloc_ctx *alloc_ctx;
+
+   unsigned long image_length;
+
+   struct o2xxx_camera_buffer *active;
+   spinlock_t lock;/* Protects video buffer lists */
+   struct list_head capture;
+   int streaming;
+   int smode;
+   int overrun;
+
+   struct i2c_client *client;
+   struct v4l2_subdev *fsubdev;
+
+   /* for sclpc fifo bestcomm */
+   struct mpc52xx_lpbfifo_request req;
+   int dmareq_queued;
+   int dma_running;
+};
+
+static int o2xxx_queue_dma_request(struct o2d_csi_priv *priv);
+static void o2xxx_bus_master_clo

Re: [PATCH 1/3] ov7670: use the control framework

2012-09-28 Thread javier Martin
Hi Hans,

On 28 September 2012 10:23, Hans Verkuil  wrote:
> On Fri September 28 2012 09:48:01 Javier Martin wrote:
>>  static const struct v4l2_subdev_core_ops ov7670_core_ops = {
>>   .g_chip_ident = ov7670_g_chip_ident,
>> - .g_ctrl = ov7670_g_ctrl,
>> - .s_ctrl = ov7670_s_ctrl,
>> - .queryctrl = ov7670_queryctrl,
>> + .g_ext_ctrls = v4l2_subdev_g_ext_ctrls,
>> + .try_ext_ctrls = v4l2_subdev_try_ext_ctrls,
>> + .s_ext_ctrls = v4l2_subdev_s_ext_ctrls,
>> + .g_ctrl = v4l2_subdev_g_ctrl,
>> + .s_ctrl = v4l2_subdev_s_ctrl,
>> + .queryctrl = v4l2_subdev_queryctrl,
>> + .querymenu = v4l2_subdev_querymenu,
>
> Can you make a fourth patch removing these lines again after mcam-core and
> via-camera are converted to the control framework? These control ops are
> only needed if there are bridge drivers using this sensor driver that are
> not yet converted to the control framework. Since that limitation is now
> lifted, these ops can be removed as well.

Fine, I will do that.

>>   .reset = ov7670_reset,
>>   .init = ov7670_init,
>>  #ifdef CONFIG_VIDEO_ADV_DEBUG
>> @@ -1732,7 +1630,6 @@ static int ov7670_probe(struct i2c_client *client,
>>
>>   info->devtype = &ov7670_devdata[id->driver_data];
>>   info->fmt = &ov7670_formats[0];
>> - info->sat = 128;/* Review this */
>>   info->clkrc = 0;
>>
>>   /* Set default frame rate to 30 fps */
>> @@ -1743,6 +1640,42 @@ static int ov7670_probe(struct i2c_client *client,
>>   if (info->pclk_hb_disable)
>>   ov7670_write(sd, REG_COM10, COM10_PCLK_HB);
>>
>> + v4l2_ctrl_handler_init(&info->hdl, 10);
>> + v4l2_ctrl_new_std(&info->hdl, &ov7670_ctrl_ops,
>> + V4L2_CID_BRIGHTNESS, 0, 255, 1, 128);
>> + v4l2_ctrl_new_std(&info->hdl, &ov7670_ctrl_ops,
>> + V4L2_CID_CONTRAST, 0, 127, 1, 64);
>> + v4l2_ctrl_new_std(&info->hdl, &ov7670_ctrl_ops,
>> + V4L2_CID_VFLIP, 0, 1, 1, 0);
>> + v4l2_ctrl_new_std(&info->hdl, &ov7670_ctrl_ops,
>> + V4L2_CID_HFLIP, 0, 1, 1, 0);
>> + info->saturation = v4l2_ctrl_new_std(&info->hdl, &ov7670_ctrl_ops,
>> + V4L2_CID_SATURATION, 0, 256, 1, 128);
>> + info->hue = v4l2_ctrl_new_std(&info->hdl, &ov7670_ctrl_ops,
>> + V4L2_CID_HUE, -180, 180, 5, 0);
>> + info->gain = v4l2_ctrl_new_std(&info->hdl, &ov7670_ctrl_ops,
>> + V4L2_CID_GAIN, 0, 255, 1, 128);
>> + info->auto_gain = v4l2_ctrl_new_std(&info->hdl, &ov7670_ctrl_ops,
>> + V4L2_CID_AUTOGAIN, 0, 1, 1, 1);
>> + info->exposure = v4l2_ctrl_new_std(&info->hdl, &ov7670_ctrl_ops,
>> + V4L2_CID_EXPOSURE, 0, 65535, 1, 500);
>> + info->auto_exposure = v4l2_ctrl_new_std_menu(&info->hdl, 
>> &ov7670_ctrl_ops,
>> + V4L2_CID_EXPOSURE_AUTO, 1, 0, 0);
>> + sd->ctrl_handler = &info->hdl;
>> + if (info->hdl.error) {
>> + int err = info->hdl.error;
>> +
>> + v4l2_ctrl_handler_free(&info->hdl);
>> + kfree(info);
>> + return err;
>> + }
>> + info->gain->flags |= V4L2_CTRL_FLAG_VOLATILE;
>> + info->exposure->flags |= V4L2_CTRL_FLAG_VOLATILE;
>> + v4l2_ctrl_cluster(2, &info->auto_gain);
>> + v4l2_ctrl_cluster(2, &info->auto_exposure);
>
> You need to use v4l2_ctrl_auto_cluster for these two. Not having that function
> at the time was the reason my work on this driver stalled. The auto cluster
> functionality takes care of most of the nitty gritty details of handling
> these situations.

OK, let me take a look.

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


  1   2   >