[PATCH RFC] [media] dvb: remove bogus modulation check

[Mauro Carvalho Chehab]

This code is wrong as I should have coded it as SYS_DVBC, instead of
SYS_DVBS & friends. Anyway, this check has other problems

1) it does some "magic" by assuming that all QAM modulations are below
  QAM_AUTO;

2) it checks modulation parameters only for one delivery system.
   Or the core should check invalid parameters for all delivery
   systems, or it should let the frontend drivers do it;

3) frontend drivers should already be checking for invalid parameters
   (most of them do it, anyway);

4) not all modulations are mapped at fe->ops.info.caps, so it is not
   even possible to check for the valid modulations inside the core
   for some delivery systems;

5) The core check is incomplete anyway: it only checks for a few
   parameters. If moved into the core other parameters like bandwidth
   and fec should also be checked;

6) 2nd gen DVB-C uses OFDM. So, that test would fail for it.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/dvb/dvb-core/dvb_frontend.c |   23 ---
 1 files changed, 0 insertions(+), 23 deletions(-)

diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c 
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index 0e079a1..a904793 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -897,29 +897,6 @@ static int dvb_frontend_check_parameters(struct 
dvb_frontend *fe)
break;
}
 
-   /*
-* check for supported modulation
-*
-* This is currently hacky. Also, it only works for DVB-S & friends,
-* and not all modulations has FE_CAN flags
-*/
-   switch (c->delivery_system) {
-   case SYS_DVBS:
-   case SYS_DVBS2:
-   case SYS_TURBO:
-   if ((c->modulation > QAM_AUTO ||
-   !((1 << (c->modulation + 10)) & fe->ops.info.caps))) {
-   printk(KERN_WARNING
-  "DVB: adapter %i frontend %i modulation %u not 
supported\n",
-  fe->dvb->num, fe->id, c->modulation);
-   return -EINVAL;
-   }
-   break;
-   default:
-   /* FIXME: it makes sense to validate othere delsys here */
-   break;
-   }
-
return 0;
 }
 
-- 
1.7.7.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] [media] drxk_hard: Remove dead code

[Mauro Carvalho Chehab]

As reported by Oliver, some old dead code were preserved there.

Thanks-to: Oliver endriss 
Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/dvb/frontends/drxk_hard.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/media/dvb/frontends/drxk_hard.c 
b/drivers/media/dvb/frontends/drxk_hard.c
index 97670db..6980ed7 100644
--- a/drivers/media/dvb/frontends/drxk_hard.c
+++ b/drivers/media/dvb/frontends/drxk_hard.c
@@ -6236,8 +6236,6 @@ static int drxk_set_parameters(struct dvb_frontend *fe)
SetOperationMode(state, OM_QAM_ITU_C);
else
SetOperationMode(state, OM_QAM_ITU_A);
-   break;
-   state->m_itut_annex_c = true;
break;
case SYS_DVBT:
if (!state->m_hasDVBT)
-- 
1.7.7.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: [git:v4l-dvb/for_v3.3] [media] dvb_frontend: Don't use ops->info.type anymore

[Mauro Carvalho Chehab]

On 07-01-2012 03:18, Oliver Endriss wrote:
> On Saturday 07 January 2012 03:05:40 Mauro Carvalho Chehab wrote:
>> On 06-01-2012 22:36, Oliver Endriss wrote:
>>> On Wednesday 04 January 2012 20:29:36 Mauro Carvalho Chehab wrote:
  drivers/media/dvb/dvb-core/dvb_frontend.c |  541 
 ++---
  1 files changed, 266 insertions(+), 275 deletions(-)
 ...
 -static int dvb_frontend_check_parameters(struct dvb_frontend *fe,
 -  struct dvb_frontend_parameters *parms)
 +static int dvb_frontend_check_parameters(struct dvb_frontend *fe)
  {
 ...
 -  /* check for supported modulation */
 -  if (fe->ops.info.type == FE_QAM &&
 -  (parms->u.qam.modulation > QAM_AUTO ||
 -   !((1 << (parms->u.qam.modulation + 10)) & fe->ops.info.caps))) {
 -  printk(KERN_WARNING "DVB: adapter %i frontend %i modulation %u 
 not supported\n",
 - fe->dvb->num, fe->id, parms->u.qam.modulation);
 +  /*
 +   * check for supported modulation
 +   *
 +   * This is currently hacky. Also, it only works for DVB-S & friends,
 +   * and not all modulations has FE_CAN flags
 +   */
 +  switch (c->delivery_system) {
 +  case SYS_DVBS:
 +  case SYS_DVBS2:
 +  case SYS_TURBO:
 +  if ((c->modulation > QAM_AUTO ||
 +  !((1 << (c->modulation + 10)) & fe->ops.info.caps))) {
>>> ^^
 +  printk(KERN_WARNING
 + "DVB: adapter %i frontend %i modulation %u not 
 supported\n",
 + fe->dvb->num, fe->id, c->modulation);
return -EINVAL;
 +  }
 +  break;
 ...
>>>
>>> This code is completely bogus: I get tons of warnings, if vdr tries to
>>> tune to DVB-S2 (modulation == 9 == PSK_8) on my stv090x.
>>>
>>> PSK_8 == 9 is > QAM_AUTO, and the shift operation does not make much
>>> sense, except for modulation == 0 == QPSK.
>>>
>>> The original version makes more sense for me.
>>
>> Oliver,
>>
>> At least for DVBv3 calls, the old code will also generate bogus
>> warnings if you try to use a DVBv3 call to set PSK_8.
> 
> No, since the checks were only performed for type==QAM, i.e. DVB-C.
> So DVB-S2 was not affected before.

Sorry, I coded it wrong.

Anyway, when DVB-C2 will be added, the code will likely break again.

>> I almost removed this validation code during the conversion for several
>> reasons:
>>
>> 1) it does some "magic" by assuming that all QAM modulations are below
>>   QAM_AUTO;
>>
>> 2) it checks modulation parameters only for DVB-S. IMO, or the core should
>> invalid parameters for all delivery systems, or should let the frontend
>> drivers do it;
>>
>> 3) frontend drivers should already be checking for invalid parameters
>> (most of them do it, anyway);
>>
>> 4) not all modulations are mapped at fe->ops.info.caps, so it is not
>> even possible to check for the valid modulations inside the core for
>> some delivery systems;
>>
>> 5) Why the core checks just the modulation, and doesn't check for other
>> types of invalid parameters, like FEC and bandwidth?
>>
>> At the end, I decided to keep it, but added that note, as I really didn't
>> like that part of the code.
>>
>> I can see two fixes for this:
>>
>> a) just remove the validation, and let the frontend check what's
>>supported;
>>
>> b) rewrite the code with a per-standard table of valid values.
>>
>> I vote for removing the validation logic there.
> 
> Ack.
> 
> Atm the core could only do proper checks for frontends, which support a
> single delivery system. For multi-delsys frontends some values of the
> info struct might not apply to the currently selected delivery system.
> 
> To fix this, you need precise information, what is supported for a given
> delivery system. In this case we need 'per delivery system' information.
> Maybe it would make sense to add a callback, and let the driver do the
> checks?

With the changes I made, all frontends are now filling ops.delsys with
the supported delivery system. The DVB core picks ops.delsys[0] during
register and on cache clear. So, no callback is needed, and the core can
quickly check the supported delivery systems.

> Furthermore, old API-5 applications do not set the delivery system!

In this case, it will use ops.delsys[0]. On all frondends with 2G support,
the first delivery system is the 1 gen.

> For example: VDR checked the FE_CAN_2G_MODULATION flag and eventually
> issues a tune call, no matter whether the current delsys is DVB-S or
> DVB-S2. So it is difficult to do check parameters in a precise way,
> while keeping backward compatibility.

Yes. Still, the frontend may not do the right thing, as it may use different
checks for SYS_DVBS/SYS_DVBS2 internally.

I did not touch (at least not intentionally) on any of such checks, but a
quick grep f

Re: [git:v4l-dvb/for_v3.3] [media] dvb_frontend: Don't use ops->info.type anymore

[Oliver Endriss]

On Saturday 07 January 2012 03:05:40 Mauro Carvalho Chehab wrote:
> On 06-01-2012 22:36, Oliver Endriss wrote:
> > On Wednesday 04 January 2012 20:29:36 Mauro Carvalho Chehab wrote:
> >>  drivers/media/dvb/dvb-core/dvb_frontend.c |  541 
> >> ++---
> >>  1 files changed, 266 insertions(+), 275 deletions(-)
> >> ...
> >> -static int dvb_frontend_check_parameters(struct dvb_frontend *fe,
> >> -  struct dvb_frontend_parameters *parms)
> >> +static int dvb_frontend_check_parameters(struct dvb_frontend *fe)
> >>  {
> >> ...
> >> -  /* check for supported modulation */
> >> -  if (fe->ops.info.type == FE_QAM &&
> >> -  (parms->u.qam.modulation > QAM_AUTO ||
> >> -   !((1 << (parms->u.qam.modulation + 10)) & fe->ops.info.caps))) {
> >> -  printk(KERN_WARNING "DVB: adapter %i frontend %i modulation %u 
> >> not supported\n",
> >> - fe->dvb->num, fe->id, parms->u.qam.modulation);
> >> +  /*
> >> +   * check for supported modulation
> >> +   *
> >> +   * This is currently hacky. Also, it only works for DVB-S & friends,
> >> +   * and not all modulations has FE_CAN flags
> >> +   */
> >> +  switch (c->delivery_system) {
> >> +  case SYS_DVBS:
> >> +  case SYS_DVBS2:
> >> +  case SYS_TURBO:
> >> +  if ((c->modulation > QAM_AUTO ||
> >> +  !((1 << (c->modulation + 10)) & fe->ops.info.caps))) {
> > ^^
> >> +  printk(KERN_WARNING
> >> + "DVB: adapter %i frontend %i modulation %u not 
> >> supported\n",
> >> + fe->dvb->num, fe->id, c->modulation);
> >>return -EINVAL;
> >> +  }
> >> +  break;
> >> ...
> > 
> > This code is completely bogus: I get tons of warnings, if vdr tries to
> > tune to DVB-S2 (modulation == 9 == PSK_8) on my stv090x.
> > 
> > PSK_8 == 9 is > QAM_AUTO, and the shift operation does not make much
> > sense, except for modulation == 0 == QPSK.
> > 
> > The original version makes more sense for me.
> 
> Oliver,
> 
> At least for DVBv3 calls, the old code will also generate bogus
> warnings if you try to use a DVBv3 call to set PSK_8.

No, since the checks were only performed for type==QAM, i.e. DVB-C.
So DVB-S2 was not affected before.

> I almost removed this validation code during the conversion for several
> reasons:
> 
> 1) it does some "magic" by assuming that all QAM modulations are below
>   QAM_AUTO;
> 
> 2) it checks modulation parameters only for DVB-S. IMO, or the core should
> invalid parameters for all delivery systems, or should let the frontend
> drivers do it;
> 
> 3) frontend drivers should already be checking for invalid parameters
> (most of them do it, anyway);
> 
> 4) not all modulations are mapped at fe->ops.info.caps, so it is not
> even possible to check for the valid modulations inside the core for
> some delivery systems;
> 
> 5) Why the core checks just the modulation, and doesn't check for other
> types of invalid parameters, like FEC and bandwidth?
> 
> At the end, I decided to keep it, but added that note, as I really didn't
> like that part of the code.
> 
> I can see two fixes for this:
> 
> a) just remove the validation, and let the frontend check what's
>supported;
> 
> b) rewrite the code with a per-standard table of valid values.
> 
> I vote for removing the validation logic there.

Ack.

Atm the core could only do proper checks for frontends, which support a
single delivery system. For multi-delsys frontends some values of the
info struct might not apply to the currently selected delivery system.

To fix this, you need precise information, what is supported for a given
delivery system. In this case we need 'per delivery system' information.
Maybe it would make sense to add a callback, and let the driver do the
checks?

Furthermore, old API-5 applications do not set the delivery system!

For example: VDR checked the FE_CAN_2G_MODULATION flag and eventually
issues a tune call, no matter whether the current delsys is DVB-S or
DVB-S2. So it is difficult to do check parameters in a precise way,
while keeping backward compatibility.

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/

--
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: Broken ioctl error returns (was Re: [PATCH 2/3] block: fail SCSI passthrough ioctls on partition devices)

[Mauro Carvalho Chehab]

On 05-01-2012 17:09, Mauro Carvalho Chehab wrote:
> On 05-01-2012 15:47, Linus Torvalds wrote:
 
>> Can you test the patch with some media capture apps (preferably with
>> the obvious fix for the problem that Paulo already pointed out -
>> although that won't actually matter until some block driver starts
>> using ENOIOCTLCMD there, so even the unfixed patch should mostly work
>> for testing)?
> 
> Sure. I'm currently traveling, so I have just my "first aids kit" of devices
> but they should be enough for testing it. I'll return you as soon as I finish
> compiling the kernel on this slow 4 years-old notebook and run some
> tests with the usual applications.

I did a quick test today: didn't notice any regressions with the usual
applications.

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: [git:v4l-dvb/for_v3.3] [media] dvb_frontend: Don't use ops->info.type anymore

[Mauro Carvalho Chehab]

On 06-01-2012 22:36, Oliver Endriss wrote:
> On Wednesday 04 January 2012 20:29:36 Mauro Carvalho Chehab wrote:
>>  drivers/media/dvb/dvb-core/dvb_frontend.c |  541 
>> ++---
>>  1 files changed, 266 insertions(+), 275 deletions(-)
>> ...
>> -static int dvb_frontend_check_parameters(struct dvb_frontend *fe,
>> -struct dvb_frontend_parameters *parms)
>> +static int dvb_frontend_check_parameters(struct dvb_frontend *fe)
>>  {
>> ...
>> -/* check for supported modulation */
>> -if (fe->ops.info.type == FE_QAM &&
>> -(parms->u.qam.modulation > QAM_AUTO ||
>> - !((1 << (parms->u.qam.modulation + 10)) & fe->ops.info.caps))) {
>> -printk(KERN_WARNING "DVB: adapter %i frontend %i modulation %u 
>> not supported\n",
>> -   fe->dvb->num, fe->id, parms->u.qam.modulation);
>> +/*
>> + * check for supported modulation
>> + *
>> + * This is currently hacky. Also, it only works for DVB-S & friends,
>> + * and not all modulations has FE_CAN flags
>> + */
>> +switch (c->delivery_system) {
>> +case SYS_DVBS:
>> +case SYS_DVBS2:
>> +case SYS_TURBO:
>> +if ((c->modulation > QAM_AUTO ||
>> +!((1 << (c->modulation + 10)) & fe->ops.info.caps))) {
> ^^
>> +printk(KERN_WARNING
>> +   "DVB: adapter %i frontend %i modulation %u not 
>> supported\n",
>> +   fe->dvb->num, fe->id, c->modulation);
>>  return -EINVAL;
>> +}
>> +break;
>> ...
> 
> This code is completely bogus: I get tons of warnings, if vdr tries to
> tune to DVB-S2 (modulation == 9 == PSK_8) on my stv090x.
> 
> PSK_8 == 9 is > QAM_AUTO, and the shift operation does not make much
> sense, except for modulation == 0 == QPSK.
> 
> The original version makes more sense for me.

Oliver,

At least for DVBv3 calls, the old code will also generate bogus
warnings if you try to use a DVBv3 call to set PSK_8.

I almost removed this validation code during the conversion for several
reasons:

1) it does some "magic" by assuming that all QAM modulations are below
  QAM_AUTO;

2) it checks modulation parameters only for DVB-S. IMO, or the core should
invalid parameters for all delivery systems, or should let the frontend
drivers do it;

3) frontend drivers should already be checking for invalid parameters
(most of them do it, anyway);

4) not all modulations are mapped at fe->ops.info.caps, so it is not
even possible to check for the valid modulations inside the core for
some delivery systems;

5) Why the core checks just the modulation, and doesn't check for other
types of invalid parameters, like FEC and bandwidth?

At the end, I decided to keep it, but added that note, as I really didn't
like that part of the code.

I can see two fixes for this:

a) just remove the validation, and let the frontend check what's
   supported;

b) rewrite the code with a per-standard table of valid values.

I vote for removing the validation logic there.

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: Pause/Resume and flush for V4L2 codec drivers.

[vkalia]

Thanks Hans.

Yes it does solve a part of my problem - Pause/Resume. But I dont see any
command defined for Flush yet. Do you think we should add one more command
to Flush. Also, I see two more commands

#define V4L2_DEC_CMD_START   (0)
#define V4L2_DEC_CMD_STOP(1)

How should I use the above two commands for an encoding/decoding session?
I was calling start/stop to hardware in streamon/streamoff earlier.

Thanks
Vinay

> On Friday, January 06, 2012 03:31:37 vka...@codeaurora.org wrote:
>> Hi
>>
>> I am trying to implement v4l2 driver for video decoders. The problem I
>> am
>> facing is how to send pause/resume and flush commands from user-space to
>> v4l2 driver. I am thinking of using controls for this. Has anyone done
>> this before or if anyone has any ideas please let me know. Appreciate
>> your
>> help.
>
> See this patch series:
>
> http://www.mail-archive.com/linux-media@vger.kernel.org/msg40516.html
>
> Does this give you what you need?
>
> Regards,
>
>   Hans
>
>>
>> Thanks
>> Vinay
>>
>> --
>> 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
>


--
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] drxk: Fix regression introduced by commit '[media] Remove Annex A/C selection via roll-off factor'

[Oliver Endriss]

On Friday 06 January 2012 20:11:56 Mauro Carvalho Chehab wrote:
> On 04-01-2012 16:45, Oliver Endriss wrote:
> > Fix regression introduced by commit '[media] Remove Annex A/C selection via 
> > roll-off factor'
> > As a result of this commit, DVB-T tuning did not work anymore.
> > 
> > Signed-off-by: Oliver Endriss 
> > 
> > diff --git a/drivers/media/dvb/frontends/drxk_hard.c 
> > b/drivers/media/dvb/frontends/drxk_hard.c
> > index 36e1c82..13f22a1 100644
> > --- a/drivers/media/dvb/frontends/drxk_hard.c
> > +++ b/drivers/media/dvb/frontends/drxk_hard.c
> > @@ -6235,6 +6235,8 @@ static int drxk_set_parameters(struct dvb_frontend 
> > *fe)
> > case SYS_DVBC_ANNEX_C:
> > state->m_itut_annex_c = true;
> > break;
> > +   case SYS_DVBT:
> > +   break;
> > default:
> > return -EINVAL;
> > }
> > 
> Hi Oliver,
> 
> Thanks for the patch! 
> 
> It become obsoleted by the patch that converted the driver
> to create just one frontend:
>   
> http://git.linuxtv.org/media_tree.git/commitdiff/fa4b2a171d42ffc512b3a86922ad68e1355eb17a

Agreed.

> While I don't have DVB-T signal here, the logs were showing that the driver is
> switching properly between DVB-T and DVB-C.
> 
> Yet, I'd appreciate if you could test it with a real signal,
> for us to be 100% sure that everything is working as expected.

A quick test showed that switching to DVB-T works.
Sorry, I do not have a DVB-C signal here.

Btw, there are two lines, which are not harmful, but should be removed
(bad formatting/dead code).

--- drxk_hard.c.old 2012-01-07 01:40:00.0 +0100
+++ drxk_hard.c 2012-01-07 01:40:30.0 +0100
@@ -6236,8 +6236,6 @@ static int drxk_set_parameters(struct dv
SetOperationMode(state, OM_QAM_ITU_C);
else
SetOperationMode(state, OM_QAM_ITU_A);
-   break;
-   state->m_itut_annex_c = true;
break;
case SYS_DVBT:
if (!state->m_hasDVBT)


CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/

--
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.3] [media] dvb_frontend: Don't use ops->info.type anymore

[Oliver Endriss]

On Wednesday 04 January 2012 20:29:36 Mauro Carvalho Chehab wrote:
>  drivers/media/dvb/dvb-core/dvb_frontend.c |  541 
> ++---
>  1 files changed, 266 insertions(+), 275 deletions(-)
> ...
> -static int dvb_frontend_check_parameters(struct dvb_frontend *fe,
> - struct dvb_frontend_parameters *parms)
> +static int dvb_frontend_check_parameters(struct dvb_frontend *fe)
>  {
> ...
> - /* check for supported modulation */
> - if (fe->ops.info.type == FE_QAM &&
> - (parms->u.qam.modulation > QAM_AUTO ||
> -  !((1 << (parms->u.qam.modulation + 10)) & fe->ops.info.caps))) {
> - printk(KERN_WARNING "DVB: adapter %i frontend %i modulation %u 
> not supported\n",
> -fe->dvb->num, fe->id, parms->u.qam.modulation);
> + /*
> +  * check for supported modulation
> +  *
> +  * This is currently hacky. Also, it only works for DVB-S & friends,
> +  * and not all modulations has FE_CAN flags
> +  */
> + switch (c->delivery_system) {
> + case SYS_DVBS:
> + case SYS_DVBS2:
> + case SYS_TURBO:
> + if ((c->modulation > QAM_AUTO ||
> + !((1 << (c->modulation + 10)) & fe->ops.info.caps))) {
^^
> + printk(KERN_WARNING
> +"DVB: adapter %i frontend %i modulation %u not 
> supported\n",
> +fe->dvb->num, fe->id, c->modulation);
>   return -EINVAL;
> + }
> + break;
> ...

This code is completely bogus: I get tons of warnings, if vdr tries to
tune to DVB-S2 (modulation == 9 == PSK_8) on my stv090x.

PSK_8 == 9 is > QAM_AUTO, and the shift operation does not make much
sense, except for modulation == 0 == QPSK.

The original version makes more sense for me.

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/

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

cx231xx: possible circular locking dependency detected on 3.2

[Thomas Petazzoni]

Hello,

I'm running the Hauppauge USB-Live 2 device on an ARM OMAP3 platform.
After loading the cx231xx driver and launching v4l2grab, I immediately
get:

[  407.087158] cx231xx #0:  setPowerMode::mode = 48, No Change req.
[  407.145477] 
[  407.147064] ==
[  407.153533] [ INFO: possible circular locking dependency detected ]
[  407.160095] 3.2.0-7-gb928298 #18
[  407.163848] ---
[  407.170410] v4l2grab/680 is trying to acquire lock:
[  407.175537]  (&mm->mmap_sem){++}, at: [] 
videobuf_qbuf+0x298/0x48c [videobuf_core]
[  407.184783] 
[  407.184783] but task is already holding lock:
[  407.190887]  (&dev->lock#2){+.+.+.}, at: [] v4l2_ioctl+0xec/0x150 
[videodev]
[  407.199249] 
[  407.199249] which lock already depends on the new lock.
[  407.199249] 
[  407.207824] 
[  407.207824] the existing dependency chain (in reverse order) is:
[  407.215667] 
[  407.215667] -> #1 (&dev->lock#2){+.+.+.}:
[  407.221435][] lock_acquire+0x98/0x100
[  407.226928][] mutex_lock_interruptible_nested+0x4c/0x37c
[  407.234161][] v4l2_mmap+0x94/0xac [videodev]
[  407.240295][] mmap_region+0x2d4/0x468
[  407.245788][] sys_mmap_pgoff+0x78/0xc0
[  407.251342][] ret_fast_syscall+0x0/0x3c
[  407.257019] 
[  407.257019] -> #0 (&mm->mmap_sem){++}:
[  407.262878][] __lock_acquire+0x1d04/0x1d94
[  407.268829][] lock_acquire+0x98/0x100
[  407.274291][] down_read+0x2c/0x3c
[  407.279418][] videobuf_qbuf+0x298/0x48c [videobuf_core]
[  407.286529][] __video_do_ioctl+0x500/0x55a8 [videodev]
[  407.293579][] video_usercopy+0x128/0x4d8 [videodev]
[  407.300354][] v4l2_ioctl+0x88/0x150 [videodev]
[  407.306671][] do_vfs_ioctl+0x7c/0x584
[  407.312164][] sys_ioctl+0x74/0x7c
[  407.317260][] ret_fast_syscall+0x0/0x3c
[  407.322937] 
[  407.322937] other info that might help us debug this:
[  407.322937] 
[  407.331329]  Possible unsafe locking scenario:
[  407.331329] 
[  407.337524]CPU0CPU1
[  407.342285]
[  407.347015]   lock(&dev->lock);
[  407.350311]lock(&mm->mmap_sem);
[  407.356536]lock(&dev->lock);
[  407.362457]   lock(&mm->mmap_sem);
[  407.366027] 
[  407.366027]  *** DEADLOCK ***
[  407.366027] 
[  407.372253] 1 lock held by v4l2grab/680:
[  407.376342]  #0:  (&dev->lock#2){+.+.+.}, at: [] 
v4l2_ioctl+0xec/0x150 [videodev]
[  407.385162] 
[  407.385162] stack backtrace:
[  407.389739] [] (unwind_backtrace+0x0/0xf0) from [] 
(print_circular_bug+0x1d4/0x2f0)
[  407.399597] [] (print_circular_bug+0x1d4/0x2f0) from [] 
(__lock_acquire+0x1d04/0x1d94)
[  407.409729] [] (__lock_acquire+0x1d04/0x1d94) from [] 
(lock_acquire+0x98/0x100)
[  407.419219] [] (lock_acquire+0x98/0x100) from [] 
(down_read+0x2c/0x3c)
[  407.427886] [] (down_read+0x2c/0x3c) from [] 
(videobuf_qbuf+0x298/0x48c [videobuf_core])
[  407.438201] [] (videobuf_qbuf+0x298/0x48c [videobuf_core]) from 
[] (__video_do_ioctl+0x500/0x55a8 [videodev])
[  407.450469] [] (__video_do_ioctl+0x500/0x55a8 [videodev]) from 
[] (video_usercopy+0x128/0x4d8 [videodev])
[  407.462341] [] (video_usercopy+0x128/0x4d8 [videodev]) from 
[] (v4l2_ioctl+0x88/0x150 [videodev])
[  407.473480] [] (v4l2_ioctl+0x88/0x150 [videodev]) from 
[] (do_vfs_ioctl+0x7c/0x584)
[  407.483337] [] (do_vfs_ioctl+0x7c/0x584) from [] 
(sys_ioctl+0x74/0x7c)
[  407.492004] [] (sys_ioctl+0x74/0x7c) from [] 
(ret_fast_syscall+0x0/0x3c)
[  407.500915] cx231xx #0: cx231xx_stop_stream():: ep_mask = 8

Best regards,

Thomas Petazzoni
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] rc-videomate-m1f.c Rename to match remote controler name

[Samuel Rakitničan]

On Fri, 06 Jan 2012 17:32:06 +0100, Samuel Rakitničan  
 wrote:



This remote was added with support for card Compro VideoMate M1F.

This remote is shipped with various Compro cards, not this one only.

Furthermore this remote can be bought separately under name Compro
VideoMate K100.
http://compro.com.tw/en/product/k100/k100.html

So give it a proper name.


Signed-off-by: Samuel Rakitničan 


Resending a mail version for patchwork..diff --git a/drivers/media/rc/keymaps/Makefile 
b/drivers/media/rc/keymaps/Makefile
index 36e4d5e..82d898a 100644
--- a/drivers/media/rc/keymaps/Makefile
+++ b/drivers/media/rc/keymaps/Makefile
@@ -85,7 +85,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
rc-trekstor.o \
rc-tt-1500.o \
rc-twinhan1027.o \
-   rc-videomate-m1f.o \
+   rc-videomate-k100.o \
rc-videomate-s350.o \
rc-videomate-tv-pvr.o \
rc-winfast.o \
diff --git a/drivers/media/rc/keymaps/rc-videomate-k100.c 
b/drivers/media/rc/keymaps/rc-videomate-k100.c
index 3bd1de1..23ee05e 100644
--- a/drivers/media/rc/keymaps/rc-videomate-k100.c
+++ b/drivers/media/rc/keymaps/rc-videomate-k100.c
@@ -1,4 +1,4 @@
-/* videomate-m1f.h - Keytable for videomate_m1f Remote Controller
+/* videomate-k100.h - Keytable for videomate_k100 Remote Controller
  *
  * keymap imported from ir-keymaps.c
  *
@@ -13,7 +13,7 @@
 #include 
 #include 
 
-static struct rc_map_table videomate_m1f[] = {
+static struct rc_map_table videomate_k100[] = {
{ 0x01, KEY_POWER },
{ 0x31, KEY_TUNER },
{ 0x33, KEY_VIDEO },
@@ -67,27 +67,27 @@ static struct rc_map_table videomate_m1f[] = {
{ 0x18, KEY_TEXT },
 };
 
-static struct rc_map_list videomate_m1f_map = {
+static struct rc_map_list videomate_k100_map = {
.map = {
-   .scan= videomate_m1f,
-   .size= ARRAY_SIZE(videomate_m1f),
+   .scan= videomate_k100,
+   .size= ARRAY_SIZE(videomate_k100),
.rc_type = RC_TYPE_UNKNOWN, /* Legacy IR type */
-   .name= RC_MAP_VIDEOMATE_M1F,
+   .name= RC_MAP_VIDEOMATE_K100,
}
 };
 
-static int __init init_rc_map_videomate_m1f(void)
+static int __init init_rc_map_videomate_k100(void)
 {
-   return rc_map_register(&videomate_m1f_map);
+   return rc_map_register(&videomate_k100_map);
 }
 
-static void __exit exit_rc_map_videomate_m1f(void)
+static void __exit exit_rc_map_videomate_k100(void)
 {
-   rc_map_unregister(&videomate_m1f_map);
+   rc_map_unregister(&videomate_k100_map);
 }
 
-module_init(init_rc_map_videomate_m1f)
-module_exit(exit_rc_map_videomate_m1f)
+module_init(init_rc_map_videomate_k100)
+module_exit(exit_rc_map_videomate_k100)
 
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Pavel Osnova ");
diff --git a/drivers/media/video/saa7134/saa7134-input.c 
b/drivers/media/video/saa7134/saa7134-input.c
index 1b15b0d..22ecd72 100644
--- a/drivers/media/video/saa7134/saa7134-input.c
+++ b/drivers/media/video/saa7134/saa7134-input.c
@@ -755,7 +755,7 @@ int saa7134_input_init1(struct saa7134_dev *dev)
polling  = 50; /* ms */
break;
case SAA7134_BOARD_VIDEOMATE_M1F:
-   ir_codes = RC_MAP_VIDEOMATE_M1F;
+   ir_codes = RC_MAP_VIDEOMATE_K100;
mask_keycode = 0x0ff00;
mask_keyup   = 0x04;
break;
diff --git a/include/media/rc-map.h b/include/media/rc-map.h
index 183d701..f688bde 100644
--- a/include/media/rc-map.h
+++ b/include/media/rc-map.h
@@ -147,7 +147,7 @@ void rc_map_init(void);
 #define RC_MAP_TREKSTOR  "rc-trekstor"
 #define RC_MAP_TT_1500   "rc-tt-1500"
 #define RC_MAP_TWINHAN_VP1027_DVBS   "rc-twinhan1027"
-#define RC_MAP_VIDEOMATE_M1F "rc-videomate-m1f"
+#define RC_MAP_VIDEOMATE_K100"rc-videomate-k100"
 #define RC_MAP_VIDEOMATE_S350"rc-videomate-s350"
 #define RC_MAP_VIDEOMATE_TV_PVR  "rc-videomate-tv-pvr"
 #define RC_MAP_WINFAST   "rc-winfast"

Re: em28xx: no sound on board 1b80:e309 (sveon stv40)

[Mario Ceresa]

Hi Mauro,
Here it is. Does the "Signed-off-by:" go in the changelog, right?

Many thanks to all the developers for the hard work: it is a joy to
see the card working :)

Best,

Mario

On 6 January 2012 20:21, Mauro Carvalho Chehab  wrote:
> On 06-01-2012 17:16, Mario Ceresa wrote:
>> Hello Devin, you're right: here it goes!
>
> Hi Mario,
>
> Plese send it with your Signed-off-by:
>
> It is a requirement for merging the patches upstream.
>>
>> Best,
>>
>> Mario
>>
>> On 6 January 2012 19:33, Devin Heitmueller  
>> wrote:
>>> On Fri, Jan 6, 2012 at 1:29 PM, Mario Ceresa  wrote:
 Ok boys: just to let you know that everything works now.

 thinking that the problem was with the audio input, I noticed that
 card=64 had an amux while card=19 no.

 .amux     = EM28XX_AMUX_LINE_IN,

 So I tried this card and modified the mplayer options accordingly:

 mplayer -tv 
 device=/dev/video0:input=0:norm=PAL:forceaudio:alsa:immediatemode=0:audiorate=48000:amode=1:adevice=hw.2
 tv://

 notice the forceaudio parameter that reads the audio even if no source
 is reported from v4l (The same approach with card=19 does not work)

 The output was a bit slugglish so I switched off pulse audio control
 of the board (https://bbs.archlinux.org/viewtopic.php?id=114228) and
 now everything is ok!

 I hope this will help some lonenly googlers in the future :)

 Regards,

 Mario
>>>
>>> Hi Mario,
>>>
>>> Since you've spent the time to figure out the details of your
>>> particular hardware, you should really consider submitting a patch to
>>> the em28xx driver which adds your device's USB ID.  That would allow
>>> others who have that hardware to have it work "out of the box" with no
>>> need for figuring out the correct "cardid" value through
>>> experimentation as you had to.
>>>
>>> Cheers,
>>>
>>> Devin
>>>
>>> --
>>> Devin J. Heitmueller - Kernel Labs
>>> http://www.kernellabs.com
>
From 4599c56dedc80ec345ed87bbbae36eaa02184235 Mon Sep 17 00:00:00 2001
From: Mario Ceresa 
Date: Fri, 6 Jan 2012 20:00:12 +0100
Subject: [PATCH] Added model Sveon STV40

Signed-off-by: Mario Ceresa 
---
 linux/drivers/media/video/em28xx/em28xx-cards.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/linux/drivers/media/video/em28xx/em28xx-cards.c b/linux/drivers/media/video/em28xx/em28xx-cards.c
index 6cab22d..d79c5d1 100644
--- a/linux/drivers/media/video/em28xx/em28xx-cards.c
+++ b/linux/drivers/media/video/em28xx/em28xx-cards.c
@@ -2033,6 +2033,8 @@ struct usb_device_id em28xx_id_table[] = {
 			.driver_info = EM28174_BOARD_PCTV_460E },
 	{ USB_DEVICE(0x2040, 0x1605),
 			.driver_info = EM2884_BOARD_HAUPPAUGE_WINTV_HVR_930C },
+	{ USB_DEVICE(0x1b80, 0xe309), /* Sveon STV40 */
+			.driver_info = EM2860_BOARD_EASYCAP }, 
 	{ },
 };
 MODULE_DEVICE_TABLE(usb, em28xx_id_table);
-- 
1.7.7.5

Re: em28xx: no sound on board 1b80:e309 (sveon stv40)

[Mauro Carvalho Chehab]

On 06-01-2012 17:16, Mario Ceresa wrote:
> Hello Devin, you're right: here it goes!

Hi Mario,

Plese send it with your Signed-off-by:

It is a requirement for merging the patches upstream.
> 
> Best,
> 
> Mario
> 
> On 6 January 2012 19:33, Devin Heitmueller  
> wrote:
>> On Fri, Jan 6, 2012 at 1:29 PM, Mario Ceresa  wrote:
>>> Ok boys: just to let you know that everything works now.
>>>
>>> thinking that the problem was with the audio input, I noticed that
>>> card=64 had an amux while card=19 no.
>>>
>>> .amux = EM28XX_AMUX_LINE_IN,
>>>
>>> So I tried this card and modified the mplayer options accordingly:
>>>
>>> mplayer -tv 
>>> device=/dev/video0:input=0:norm=PAL:forceaudio:alsa:immediatemode=0:audiorate=48000:amode=1:adevice=hw.2
>>> tv://
>>>
>>> notice the forceaudio parameter that reads the audio even if no source
>>> is reported from v4l (The same approach with card=19 does not work)
>>>
>>> The output was a bit slugglish so I switched off pulse audio control
>>> of the board (https://bbs.archlinux.org/viewtopic.php?id=114228) and
>>> now everything is ok!
>>>
>>> I hope this will help some lonenly googlers in the future :)
>>>
>>> Regards,
>>>
>>> Mario
>>
>> Hi Mario,
>>
>> Since you've spent the time to figure out the details of your
>> particular hardware, you should really consider submitting a patch to
>> the em28xx driver which adds your device's USB ID.  That would allow
>> others who have that hardware to have it work "out of the box" with no
>> need for figuring out the correct "cardid" value through
>> experimentation as you had to.
>>
>> Cheers,
>>
>> Devin
>>
>> --
>> Devin J. Heitmueller - Kernel Labs
>> http://www.kernellabs.com

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

Re: em28xx: no sound on board 1b80:e309 (sveon stv40)

[Mario Ceresa]

Hello Devin, you're right: here it goes!

Best,

Mario

On 6 January 2012 19:33, Devin Heitmueller  wrote:
> On Fri, Jan 6, 2012 at 1:29 PM, Mario Ceresa  wrote:
>> Ok boys: just to let you know that everything works now.
>>
>> thinking that the problem was with the audio input, I noticed that
>> card=64 had an amux while card=19 no.
>>
>> .amux     = EM28XX_AMUX_LINE_IN,
>>
>> So I tried this card and modified the mplayer options accordingly:
>>
>> mplayer -tv 
>> device=/dev/video0:input=0:norm=PAL:forceaudio:alsa:immediatemode=0:audiorate=48000:amode=1:adevice=hw.2
>> tv://
>>
>> notice the forceaudio parameter that reads the audio even if no source
>> is reported from v4l (The same approach with card=19 does not work)
>>
>> The output was a bit slugglish so I switched off pulse audio control
>> of the board (https://bbs.archlinux.org/viewtopic.php?id=114228) and
>> now everything is ok!
>>
>> I hope this will help some lonenly googlers in the future :)
>>
>> Regards,
>>
>> Mario
>
> Hi Mario,
>
> Since you've spent the time to figure out the details of your
> particular hardware, you should really consider submitting a patch to
> the em28xx driver which adds your device's USB ID.  That would allow
> others who have that hardware to have it work "out of the box" with no
> need for figuring out the correct "cardid" value through
> experimentation as you had to.
>
> Cheers,
>
> Devin
>
> --
> Devin J. Heitmueller - Kernel Labs
> http://www.kernellabs.com
From dd334663b202eb0569b506273c75f3a0ede6b803 Mon Sep 17 00:00:00 2001
From: Mario Ceresa 
Date: Fri, 6 Jan 2012 20:00:12 +0100
Subject: [PATCH] Added model Sveon STV40

---
 linux/drivers/media/video/em28xx/em28xx-cards.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/linux/drivers/media/video/em28xx/em28xx-cards.c b/linux/drivers/media/video/em28xx/em28xx-cards.c
index 6cab22d..d79c5d1 100644
--- a/linux/drivers/media/video/em28xx/em28xx-cards.c
+++ b/linux/drivers/media/video/em28xx/em28xx-cards.c
@@ -2033,6 +2033,8 @@ struct usb_device_id em28xx_id_table[] = {
 			.driver_info = EM28174_BOARD_PCTV_460E },
 	{ USB_DEVICE(0x2040, 0x1605),
 			.driver_info = EM2884_BOARD_HAUPPAUGE_WINTV_HVR_930C },
+	{ USB_DEVICE(0x1b80, 0xe309), /* Sveon STV40 */
+			.driver_info = EM2860_BOARD_EASYCAP }, 
 	{ },
 };
 MODULE_DEVICE_TABLE(usb, em28xx_id_table);
-- 
1.7.7.5

Re: [PATCH] drxk: Fix regression introduced by commit '[media] Remove Annex A/C selection via roll-off factor'

[Mauro Carvalho Chehab]

On 04-01-2012 16:45, Oliver Endriss wrote:
> Fix regression introduced by commit '[media] Remove Annex A/C selection via 
> roll-off factor'
> As a result of this commit, DVB-T tuning did not work anymore.
> 
> Signed-off-by: Oliver Endriss 
> 
> diff --git a/drivers/media/dvb/frontends/drxk_hard.c 
> b/drivers/media/dvb/frontends/drxk_hard.c
> index 36e1c82..13f22a1 100644
> --- a/drivers/media/dvb/frontends/drxk_hard.c
> +++ b/drivers/media/dvb/frontends/drxk_hard.c
> @@ -6235,6 +6235,8 @@ static int drxk_set_parameters(struct dvb_frontend *fe)
>   case SYS_DVBC_ANNEX_C:
>   state->m_itut_annex_c = true;
>   break;
> + case SYS_DVBT:
> + break;
>   default:
>   return -EINVAL;
>   }
> 
Hi Oliver,

Thanks for the patch! 

It become obsoleted by the patch that converted the driver
to create just one frontend:

http://git.linuxtv.org/media_tree.git/commitdiff/fa4b2a171d42ffc512b3a86922ad68e1355eb17a

While I don't have DVB-T signal here, the logs were showing that the driver is
switching properly between DVB-T and DVB-C.

Yet, I'd appreciate if you could test it with a real signal,
for us to be 100% sure that everything is working as expected.

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

Re: [PATCH 0/2] Re: [git:v4l-dvb/for_v3.3] [media] dvb-bt8xx: handle errors from dvb_net_init

[Mauro Carvalho Chehab]

On 06-01-2012 16:25, Jonathan Nieder wrote:
> Hi Mauro,
> 
> Mauro Carvalho Chehab wrote:
> 
>> Subject: [media] dvb-bt8xx: handle errors from dvb_net_init
> [...]
>> [mchehab.redhat.com: codingstyle fix: printk() should include KERN_ facility 
>> level]
> [...]
>> --- a/drivers/media/dvb/bt8xx/dvb-bt8xx.c
>> +++ b/drivers/media/dvb/bt8xx/dvb-bt8xx.c
>> @@ -782,7 +782,12 @@ static int __devinit dvb_bt8xx_load_card(struct 
>> dvb_bt8xx_card *card, u32 type)
>>  goto err_remove_mem_frontend;
>>  }
>>  
>> -dvb_net_init(&card->dvb_adapter, &card->dvbnet, &card->demux.dmx);
>> +result = dvb_net_init(&card->dvb_adapter, &card->dvbnet, 
>> &card->demux.dmx);
>> +if (result < 0) {
>> +printk(KERN_ERR,
>> +   "dvb_bt8xx: dvb_net_init failed (errno = %d)\n", result);
> 
> I think there is an extra comma here:

Yeah, I noticed it, but only after adding it at the main repo :(
> 
>   $ make drivers/media/dvb/bt8xx/dvb-bt8xx.o
> CHK include/linux/version.h
> CHK include/generated/utsrelease.h
> CALLscripts/checksyscalls.sh
> CC [M]  drivers/media/dvb/bt8xx/dvb-bt8xx.o
>   drivers/media/dvb/bt8xx/dvb-bt8xx.c: In function ‘dvb_bt8xx_load_card’:
>   drivers/media/dvb/bt8xx/dvb-bt8xx.c:788:10: warning: too many arguments 
> for format [-Wformat-extra-args]
> 
> Perhaps it would be better to add the KERN_ levels throughout the file
> with a separate patch.  Like this:
> 
> Jonathan Nieder (2):
>   [media] dvb-bt8xx: use dprintk for debug statements
>   [media] dvb-bt8xx: convert printks to pr_err()
> 
>  drivers/media/dvb/bt8xx/dvb-bt8xx.c |   41 
> +--
>  1 files changed, 20 insertions(+), 21 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

cron job: media_tree daily build: ERRORS

[Hans Verkuil]

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

Results of the daily build of media_tree:

date:Fri Jan  6 19:00:28 CET 2012
git hash:bcd158de94238d90adf7275548f0aaf2de724ab1
gcc version:  i686-linux-gcc (GCC) 4.6.1
host hardware:x86_64
host os:  3.1-2.slh.1-amd64

linux-git-arm-eabi-enoxys: ERRORS
linux-git-arm-eabi-omap: ERRORS
linux-git-armv5-ixp: WARNINGS
linux-git-i686: WARNINGS
linux-git-m32r: OK
linux-git-mips: WARNINGS
linux-git-powerpc64: WARNINGS
linux-git-x86_64: WARNINGS
linux-2.6.31.12-i686: ERRORS
linux-2.6.32.6-i686: WARNINGS
linux-2.6.33-i686: WARNINGS
linux-2.6.34-i686: WARNINGS
linux-2.6.35.3-i686: WARNINGS
linux-2.6.36-i686: WARNINGS
linux-2.6.37-i686: WARNINGS
linux-2.6.38.2-i686: WARNINGS
linux-2.6.39.1-i686: WARNINGS
linux-3.0-i686: WARNINGS
linux-3.1-i686: WARNINGS
linux-3.2-rc1-i686: WARNINGS
linux-2.6.31.12-x86_64: ERRORS
linux-2.6.32.6-x86_64: WARNINGS
linux-2.6.33-x86_64: WARNINGS
linux-2.6.34-x86_64: WARNINGS
linux-2.6.35.3-x86_64: WARNINGS
linux-2.6.36-x86_64: WARNINGS
linux-2.6.37-x86_64: WARNINGS
linux-2.6.38.2-x86_64: WARNINGS
linux-2.6.39.1-x86_64: WARNINGS
linux-3.0-x86_64: WARNINGS
linux-3.1-x86_64: WARNINGS
linux-3.2-rc1-x86_64: WARNINGS
spec-git: WARNINGS
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

[PATCH] [media] dm1105: release dvbnet on frontend attachment failure

[Jonathan Nieder]

The patch "dm1105: handle errors from dvb_net_init" moved the
initialization of dvbnet to before frontend attachment but forgot
to adjust the error handling when frontend attachment fails.

Signed-off-by: Jonathan Nieder 
---
Mauro Carvalho Chehab wrote:

> Subject: [media] dm1105: handle errors from dvb_net_init
[...]
> --- a/drivers/media/dvb/dm1105/dm1105.c
> +++ b/drivers/media/dvb/dm1105/dm1105.c
> @@ -1115,11 +1115,14 @@ static int __devinit dm1105_probe(struct pci_dev 
> *pdev,
>   if (ret < 0)
>   goto err_remove_mem_frontend;
>  
> + ret = dvb_net_init(dvb_adapter, &dev->dvbnet, dmx);
> + if (ret < 0)
> + goto err_disconnect_frontend;
> +
>   ret = frontend_init(dev);
>   if (ret < 0)
>   goto err_disconnect_frontend;
>  
> - dvb_net_init(dvb_adapter, &dev->dvbnet, dmx);

This looks bogus --- my fault, sorry.  Here's a fixup on top.

If create_singlethread_workqueue or a later step fails, I suspect this
still might not clean up as much as it should.  E.g., I expected to find
something like

if (dev->fe->ops.release)
dev->fe->ops.release(dev->fe);

somewhere in the cleanup code.

 drivers/media/dvb/dm1105/dm1105.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/media/dvb/dm1105/dm1105.c 
b/drivers/media/dvb/dm1105/dm1105.c
index 70e040b999e7..a609b3a9b146 100644
--- a/drivers/media/dvb/dm1105/dm1105.c
+++ b/drivers/media/dvb/dm1105/dm1105.c
@@ -1121,7 +1121,7 @@ static int __devinit dm1105_probe(struct pci_dev *pdev,
 
ret = frontend_init(dev);
if (ret < 0)
-   goto err_disconnect_frontend;
+   goto err_dvb_net;
 
dm1105_ir_init(dev);
 
-- 
1.7.8.2

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

Re: em28xx: no sound on board 1b80:e309 (sveon stv40)

[Devin Heitmueller]

On Fri, Jan 6, 2012 at 1:29 PM, Mario Ceresa  wrote:
> Ok boys: just to let you know that everything works now.
>
> thinking that the problem was with the audio input, I noticed that
> card=64 had an amux while card=19 no.
>
> .amux     = EM28XX_AMUX_LINE_IN,
>
> So I tried this card and modified the mplayer options accordingly:
>
> mplayer -tv 
> device=/dev/video0:input=0:norm=PAL:forceaudio:alsa:immediatemode=0:audiorate=48000:amode=1:adevice=hw.2
> tv://
>
> notice the forceaudio parameter that reads the audio even if no source
> is reported from v4l (The same approach with card=19 does not work)
>
> The output was a bit slugglish so I switched off pulse audio control
> of the board (https://bbs.archlinux.org/viewtopic.php?id=114228) and
> now everything is ok!
>
> I hope this will help some lonenly googlers in the future :)
>
> Regards,
>
> Mario

Hi Mario,

Since you've spent the time to figure out the details of your
particular hardware, you should really consider submitting a patch to
the em28xx driver which adds your device's USB ID.  That would allow
others who have that hardware to have it work "out of the box" with no
need for figuring out the correct "cardid" value through
experimentation as you had to.

Cheers,

Devin

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

Re: em28xx: no sound on board 1b80:e309 (sveon stv40)

[Mario Ceresa]

Ok boys: just to let you know that everything works now.

thinking that the problem was with the audio input, I noticed that
card=64 had an amux while card=19 no.

.amux = EM28XX_AMUX_LINE_IN,

So I tried this card and modified the mplayer options accordingly:

mplayer -tv 
device=/dev/video0:input=0:norm=PAL:forceaudio:alsa:immediatemode=0:audiorate=48000:amode=1:adevice=hw.2
tv://

notice the forceaudio parameter that reads the audio even if no source
is reported from v4l (The same approach with card=19 does not work)

The output was a bit slugglish so I switched off pulse audio control
of the board (https://bbs.archlinux.org/viewtopic.php?id=114228) and
now everything is ok!

I hope this will help some lonenly googlers in the future :)

Regards,

Mario





On 6 January 2012 18:48, Mario Ceresa  wrote:
> Hello again!
>
> I managed to obtain a nice video input from my sveon usb stick using
> last em28xx v4l drivers from git and giving the module the hint
> card=19.
>
> But I have no audio.The card works flawlessy in windows.
>
> The internal chipsets in the card are:
> - USB interface: em2860
> - Audio ADC: emp202
> - Video ADC: saa7118h (philips)
>
> Attached is the relevant dmseg output.
>
> The usb audio card card correctly shows in pulseaudio volume control
> and is recognized as hw.2 by alsa:
> $ arecord -l
>  List of CAPTURE Hardware Devices 
> card 0: Intel [HDA Intel], device 0: AD198x Analog [AD198x Analog]
>  Subdevices: 3/3
>  Subdevice #0: subdevice #0
>  Subdevice #1: subdevice #1
>  Subdevice #2: subdevice #2
> card 2: STV40 [USB 2861 Device (SVEON STV40)], device 0: USB Audio [USB Audio]
>  Subdevices: 1/1
>  Subdevice #0: subdevice #0
>
> However, I'm not able to record any sound from it and mplayer says "no audio":
> $ mplayer -tv 
> device=/dev/video0:input=1:norm=PAL:alsa:immediatemode=0:audiorate=48000:amode=1:adevice=hw.2
> tv://
> MPlayer SVN-r33996-4.6.1 (C) 2000-2011 MPlayer Team
> mplayer: could not connect to socket
> mplayer: No such file or directory
> Failed to open LIRC support. You will not be able to use your remote control.
>
> Playing tv://.
> TV file format detected.
> Selected driver: v4l2
>  name: Video 4 Linux 2 input
>  author: Martin Olschewski 
>  comment: first try, more to come ;-)
> Selected device: EM2860/SAA711X Reference Design
>  Capabilities:  video capture  VBI capture device  audio  read/write  
> streaming
>  supported norms: 0 = NTSC; 1 = NTSC-M; 2 = NTSC-M-JP; 3 = NTSC-M-KR;
> 4 = NTSC-443; 5 = PAL; 6 = PAL-BG; 7 = PAL-H; 8 = PAL-I; 9 = PAL-DK;
> 10 = PAL-M; 11 = PAL-N; 12 = PAL-Nc; 13 = PAL-60; 14 = SECAM; 15 =
> SECAM-B; 16 = SECAM-G; 17 = SECAM-H; 18 = SECAM-DK; 19 = SECAM-L; 20 =
> SECAM-Lc;
>  inputs: 0 = S-Video; 1 = Composite1;
>  Current input: 1
>  Current format: YUYV
> v4l2: ioctl set format failed: Invalid argument
> v4l2: ioctl set format failed: Invalid argument
> v4l2: ioctl set format failed: Invalid argument
> Selected input hasn't got a tuner!
> ==
> Opening video decoder: [raw] RAW Uncompressed Video
> Movie-Aspect is undefined - no prescaling applied.
> VO: [vdpau] 640x480 => 640x480 Packed YUY2
> Selected video codec: [rawyuy2] vfm: raw (RAW YUY2)
> ==
> Audio: no sound
> Starting playback...
> V:   2.0  52/ 52  0%  5%  0.0% 0 0
> v4l2: 59 frames successfully processed, 0 frames dropped.
>
> Maybe has something to do with the last line in dmesg:
>
> [  403.359333] ALSA sound/usb/mixer.c:845 2:1: cannot get min/max
> values for control 2 (id 2)
>
> Any ideas?
>
> Mario
--
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] [media] dvb-bt8xx: convert printks to pr_err()

[Jonathan Nieder]

This module does some printks with the loglevel missing.

pr_err() takes care of adding the KERN_ERR tag and the module name.
So we can simplify the code and add the missing printk loglevel by
using it.

Also add a #define pr_fmt() to make this work, and remove a few
unnecessary periods at the end of messages and bump the loglevel of
"Unknown bttv card type" from KERN_WARNING to KERN_ERR while at it.

Inspired-by: Mauro Carvalho Chehab 
Signed-off-by: Jonathan Nieder 
---
 drivers/media/dvb/bt8xx/dvb-bt8xx.c |   35 +--
 1 files changed, 17 insertions(+), 18 deletions(-)

diff --git a/drivers/media/dvb/bt8xx/dvb-bt8xx.c 
b/drivers/media/dvb/bt8xx/dvb-bt8xx.c
index 2f38cca7604b..f9087a0f0cc3 100644
--- a/drivers/media/dvb/bt8xx/dvb-bt8xx.c
+++ b/drivers/media/dvb/bt8xx/dvb-bt8xx.c
@@ -19,6 +19,8 @@
  *
  */
 
+#define pr_fmt(fmt) "dvb_bt8xx: " fmt
+
 #include 
 #include 
 #include 
@@ -666,7 +668,7 @@ static void frontend_init(struct dvb_bt8xx_card *card, u32 
type)
/*  DST is not a frontend driver !!!*/
state = kmalloc(sizeof (struct dst_state), GFP_KERNEL);
if (!state) {
-   printk("dvb_bt8xx: No memory\n");
+   pr_err("No memory\n");
break;
}
/*  Setup the Card  */
@@ -676,7 +678,7 @@ static void frontend_init(struct dvb_bt8xx_card *card, u32 
type)
state->dst_ca = NULL;
/*  DST is not a frontend, attaching the ASIC   */
if (dvb_attach(dst_attach, state, &card->dvb_adapter) == NULL) {
-   printk("%s: Could not find a Twinhan DST.\n", __func__);
+   pr_err("%s: Could not find a Twinhan DST\n", __func__);
break;
}
/*  Attach other DST peripherals if any */
@@ -705,14 +707,14 @@ static void frontend_init(struct dvb_bt8xx_card *card, 
u32 type)
}
 
if (card->fe == NULL)
-   printk("dvb-bt8xx: A frontend driver was not found for device 
[%04x:%04x] subsystem [%04x:%04x]\n",
+   pr_err("A frontend driver was not found for device [%04x:%04x] 
subsystem [%04x:%04x]\n",
   card->bt->dev->vendor,
   card->bt->dev->device,
   card->bt->dev->subsystem_vendor,
   card->bt->dev->subsystem_device);
else
if (dvb_register_frontend(&card->dvb_adapter, card->fe)) {
-   printk("dvb-bt8xx: Frontend registration failed!\n");
+   pr_err("Frontend registration failed!\n");
dvb_frontend_detach(card->fe);
card->fe = NULL;
}
@@ -726,7 +728,7 @@ static int __devinit dvb_bt8xx_load_card(struct 
dvb_bt8xx_card *card, u32 type)
  THIS_MODULE, &card->bt->dev->dev,
  adapter_nr);
if (result < 0) {
-   printk("dvb_bt8xx: dvb_register_adapter failed (errno = %d)\n", 
result);
+   pr_err("dvb_register_adapter failed (errno = %d)\n", result);
return result;
}
card->dvb_adapter.priv = card;
@@ -746,7 +748,7 @@ static int __devinit dvb_bt8xx_load_card(struct 
dvb_bt8xx_card *card, u32 type)
 
result = dvb_dmx_init(&card->demux);
if (result < 0) {
-   printk("dvb_bt8xx: dvb_dmx_init failed (errno = %d)\n", result);
+   pr_err("dvb_dmx_init failed (errno = %d)\n", result);
goto err_unregister_adaptor;
}
 
@@ -756,7 +758,7 @@ static int __devinit dvb_bt8xx_load_card(struct 
dvb_bt8xx_card *card, u32 type)
 
result = dvb_dmxdev_init(&card->dmxdev, &card->dvb_adapter);
if (result < 0) {
-   printk("dvb_bt8xx: dvb_dmxdev_init failed (errno = %d)\n", 
result);
+   pr_err("dvb_dmxdev_init failed (errno = %d)\n", result);
goto err_dmx_release;
}
 
@@ -764,7 +766,7 @@ static int __devinit dvb_bt8xx_load_card(struct 
dvb_bt8xx_card *card, u32 type)
 
result = card->demux.dmx.add_frontend(&card->demux.dmx, &card->fe_hw);
if (result < 0) {
-   printk("dvb_bt8xx: dvb_dmx_init failed (errno = %d)\n", result);
+   pr_err("dvb_dmx_init failed (errno = %d)\n", result);
goto err_dmxdev_release;
}
 
@@ -772,19 +774,19 @@ static int __devinit dvb_bt8xx_load_card(struct 
dvb_bt8xx_card *card, u32 type)
 
result = card->demux.dmx.add_frontend(&card->demux.dmx, &card->fe_mem);
if (result < 0) {
-   printk("dvb_bt8xx: dvb_dmx_init failed (errno = %d)\n", result);
+   pr_err("dvb_dmx_init failed (errno = %d)\n", result);
goto err_remove_hw_frontend;
   

[PATCH 1/2] [media] dvb-bt8xx: use dprintk for debug statements

[Jonathan Nieder]

This way, the messages will be tagged with KERN_DEBUG and not clutter
the log from dmesg unless the "debug" module parameter is set.

Signed-off-by: Jonathan Nieder 
---
 drivers/media/dvb/bt8xx/dvb-bt8xx.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/dvb/bt8xx/dvb-bt8xx.c 
b/drivers/media/dvb/bt8xx/dvb-bt8xx.c
index b9d927270318..2f38cca7604b 100644
--- a/drivers/media/dvb/bt8xx/dvb-bt8xx.c
+++ b/drivers/media/dvb/bt8xx/dvb-bt8xx.c
@@ -205,7 +205,7 @@ static int cx24108_tuner_set_params(struct dvb_frontend *fe)
0x0012,0x0014};
 
#define XTAL 1011100 /* Hz, really 1.0111 MHz and a /10 prescaler */
-   printk("cx24108 debug: entering SetTunerFreq, freq=%d\n",freq);
+   dprintk("cx24108 debug: entering SetTunerFreq, freq=%d\n",freq);
 
/* This is really the bit driving the tuner chip cx24108 */
 
@@ -216,7 +216,7 @@ static int cx24108_tuner_set_params(struct dvb_frontend *fe)
 
/* decide which VCO to use for the input frequency */
for(i = 1; (i < ARRAY_SIZE(osci) - 1) && (osci[i] < freq); i++);
-   printk("cx24108 debug: select vco #%d (f=%d)\n",i,freq);
+   dprintk("cx24108 debug: select vco #%d (f=%d)\n",i,freq);
band=bandsel[i];
/* the gain values must be set by SetSymbolrate */
/* compute the pll divider needed, from Conexant data sheet,
@@ -232,7 +232,7 @@ static int cx24108_tuner_set_params(struct dvb_frontend *fe)
((a&0x1f)<<11);
/* everything is shifted left 11 bits to left-align the bits in the
   32bit word. Output to the tuner goes MSB-aligned, after all */
-   printk("cx24108 debug: pump=%d, n=%d, a=%d\n",pump,n,a);
+   dprintk("cx24108 debug: pump=%d, n=%d, a=%d\n",pump,n,a);
cx24110_pll_write(fe,band);
/* set vga and vca to their widest-band settings, as a precaution.
   SetSymbolrate might not be called to set this up */
-- 
1.7.8.2

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

[PATCH 0/2] Re: [git:v4l-dvb/for_v3.3] [media] dvb-bt8xx: handle errors from dvb_net_init

[Jonathan Nieder]

Hi Mauro,

Mauro Carvalho Chehab wrote:

> Subject: [media] dvb-bt8xx: handle errors from dvb_net_init
[...]
> [mchehab.redhat.com: codingstyle fix: printk() should include KERN_ facility 
> level]
[...]
> --- a/drivers/media/dvb/bt8xx/dvb-bt8xx.c
> +++ b/drivers/media/dvb/bt8xx/dvb-bt8xx.c
> @@ -782,7 +782,12 @@ static int __devinit dvb_bt8xx_load_card(struct 
> dvb_bt8xx_card *card, u32 type)
>   goto err_remove_mem_frontend;
>   }
>  
> - dvb_net_init(&card->dvb_adapter, &card->dvbnet, &card->demux.dmx);
> + result = dvb_net_init(&card->dvb_adapter, &card->dvbnet, 
> &card->demux.dmx);
> + if (result < 0) {
> + printk(KERN_ERR,
> +"dvb_bt8xx: dvb_net_init failed (errno = %d)\n", result);

I think there is an extra comma here:

$ make drivers/media/dvb/bt8xx/dvb-bt8xx.o
  CHK include/linux/version.h
  CHK include/generated/utsrelease.h
  CALLscripts/checksyscalls.sh
  CC [M]  drivers/media/dvb/bt8xx/dvb-bt8xx.o
drivers/media/dvb/bt8xx/dvb-bt8xx.c: In function ‘dvb_bt8xx_load_card’:
drivers/media/dvb/bt8xx/dvb-bt8xx.c:788:10: warning: too many arguments 
for format [-Wformat-extra-args]

Perhaps it would be better to add the KERN_ levels throughout the file
with a separate patch.  Like this:

Jonathan Nieder (2):
  [media] dvb-bt8xx: use dprintk for debug statements
  [media] dvb-bt8xx: convert printks to pr_err()

 drivers/media/dvb/bt8xx/dvb-bt8xx.c |   41 +--
 1 files changed, 20 insertions(+), 21 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: Multiple channel capture support in V4l2 layer

[Dilip Mannil]

Thanks Laurent.Found similar type of discussion in this thread

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


On Tue, Jan 3, 2012 at 6:44 AM, Laurent Pinchart
 wrote:
> Hi Dilip,
>
> On Friday 23 December 2011 19:57:22 Dilip Mannil wrote:
>> Hi,
>> I am trying to implement v4l2 slave driver for  ML86V76654  digital
>> video decoder that converts NTSC, PAL, SECAM analog video signals into
>> the YCbCr standard digital format. This codec takes 4 analog inputs(2
>> analog camera + 2 ext video in) and encodes in to digital(only one at
>> a time).
>>
>> The driver should be able to switch between capture channels upon
>> request from user space application.
>>
>> I couldn't find the support for multiple capture channels on a single
>> device in v4l2 layer. Please correct me if I am wrong.
>>
>> Ideally I want the v4l2 slave driver to have following feature.
>>
>> 1. ioctl that can be used to enumerate/get/set the  capture channels
>> on the video encoder.
>> 2. Able to capture video from the currently set capture channel and
>> pass to higher layers.
>>
>> Which is the best way to implement this support?
>
> VIDIOC_ENUMINPUT and VIDIOC_[GS]_INPUT seem to be what you're looking for.
>
> --
> Regards,
>
> Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH/RFC v2 3/4] gspca: sonixj: Add V4L2_CID_JPEG_COMPRESSION_QUALITY control support

[Sylwester Nawrocki]

The JPEG compression quality value can currently be read using the
VIDIOC_G_JPEGCOMP ioctl. As the quality field of struct v4l2_jpgecomp
is being deprecated, we add the V4L2_CID_JPEG_COMPRESSION_QUALITY
control, so after the deprecation period VIDIOC_G_JPEGCOMP ioctl
handler can be removed, leaving the control the only user interface
for retrieving the compression quality.

Cc: Jean-Francois Moine 
Signed-off-by: Sylwester Nawrocki 
---
For completeness V4L2_CID_JPEG_ACTIVE_MARKER control might be 
also added.
---
 drivers/media/video/gspca/sonixj.c |   23 +++
 1 files changed, 23 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/gspca/sonixj.c 
b/drivers/media/video/gspca/sonixj.c
index c55d667..c148081 100644
--- a/drivers/media/video/gspca/sonixj.c
+++ b/drivers/media/video/gspca/sonixj.c
@@ -45,6 +45,7 @@ enum e_ctrl {
SHARPNESS,
ILLUM,
FREQ,
+   QUALITY,
NCTRLS  /* number of controls */
 };
 
@@ -126,6 +127,7 @@ static void qual_upd(struct work_struct *work);
 #define DEF_EN 0x80/* defect pixel by 0: soft, 1: hard */
 
 /* V4L2 controls supported by the driver */
+static int getjpegqual(struct gspca_dev *gspca_dev, s32 *val);
 static void setbrightness(struct gspca_dev *gspca_dev);
 static void setcontrast(struct gspca_dev *gspca_dev);
 static void setcolors(struct gspca_dev *gspca_dev);
@@ -286,6 +288,19 @@ static const struct ctrl sd_ctrls[NCTRLS] = {
},
.set_control = setfreq
},
+[QUALITY] = {
+   {
+   .id  = V4L2_CID_JPEG_COMPRESSION_QUALITY,
+   .type= V4L2_CTRL_TYPE_INTEGER,
+   .name= "Compression Quality",
+   .minimum = QUALITY_MIN,
+   .maximum = QUALITY_MAX,
+   .step= 1,
+   .default_value = QUALITY_DEF,
+   .flags   = V4L2_CTRL_FLAG_READ_ONLY,
+   },
+   .get = getjpegqual
+   },
 };
 
 /* table of the disabled controls */
@@ -2960,6 +2975,14 @@ static int sd_get_jcomp(struct gspca_dev *gspca_dev,
return 0;
 }
 
+static int getjpegqual(struct gspca_dev *gspca_dev, s32 *val)
+{
+   struct sd *sd = (struct sd *) gspca_dev;
+
+   *val = sd->quality;
+   return 0;
+}
+
 static int sd_querymenu(struct gspca_dev *gspca_dev,
struct v4l2_querymenu *menu)
 {
-- 
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/RFC v2 4/4] gspca: zc3xx: Add V4L2_CID_JPEG_COMPRESSION_QUALITY control support

[Sylwester Nawrocki]

The JPEG compression quality control is currently done by means of the
VIDIOC_S/G_JPEGCOMP ioctls. As the quality field of struct v4l2_jpgecomp
is being deprecated, we add the V4L2_CID_JPEG_COMPRESSION_QUALITY control,
so after the deprecation period VIDIOC_S/G_JPEGCOMP ioctl handlers can be
removed, leaving the control the only user interface for compression
quality configuration.

Cc: Jean-Francois Moine 
Signed-off-by: Sylwester Nawrocki 
---
For completeness V4L2_CID_JPEG_ACTIVE_MARKER control might be also added.
---
 drivers/media/video/gspca/zc3xx.c |   54 +---
 1 files changed, 37 insertions(+), 17 deletions(-)

diff --git a/drivers/media/video/gspca/zc3xx.c 
b/drivers/media/video/gspca/zc3xx.c
index f22e02f..019a93b 100644
--- a/drivers/media/video/gspca/zc3xx.c
+++ b/drivers/media/video/gspca/zc3xx.c
@@ -46,6 +46,7 @@ enum e_ctrl {
AUTOGAIN,
LIGHTFREQ,
SHARPNESS,
+   QUALITY,
NCTRLS  /* number of controls */
 };
 
@@ -57,11 +58,6 @@ struct sd {
 
struct gspca_ctrl ctrls[NCTRLS];
 
-   u8 quality; /* image quality */
-#define QUALITY_MIN 50
-#define QUALITY_MAX 80
-#define QUALITY_DEF 70
-
u8 bridge;
u8 sensor;  /* Type of image sensor chip */
u16 chip_revision;
@@ -101,6 +97,12 @@ static void setexposure(struct gspca_dev *gspca_dev);
 static int sd_setautogain(struct gspca_dev *gspca_dev, __s32 val);
 static void setlightfreq(struct gspca_dev *gspca_dev);
 static void setsharpness(struct gspca_dev *gspca_dev);
+static int sd_setquality(struct gspca_dev *gspca_dev, __s32 val);
+
+/* JPEG image quality */
+#define QUALITY_MIN 50
+#define QUALITY_MAX 80
+#define QUALITY_DEF 70
 
 static const struct ctrl sd_ctrls[NCTRLS] = {
 [BRIGHTNESS] = {
@@ -188,6 +190,18 @@ static const struct ctrl sd_ctrls[NCTRLS] = {
},
.set_control = setsharpness
},
+[QUALITY] = {
+   {
+   .id  = V4L2_CID_JPEG_COMPRESSION_QUALITY,
+   .type= V4L2_CTRL_TYPE_INTEGER,
+   .name= "Compression Quality",
+   .minimum = QUALITY_MIN,
+   .maximum = QUALITY_MAX,
+   .step= 1,
+   .default_value = QUALITY_DEF,
+   },
+   .set = sd_setquality
+   },
 };
 
 static const struct v4l2_pix_format vga_mode[] = {
@@ -6411,7 +6425,7 @@ static int sd_config(struct gspca_dev *gspca_dev,
sd->sensor = id->driver_info;
 
gspca_dev->cam.ctrls = sd->ctrls;
-   sd->quality = QUALITY_DEF;
+   sd->ctrls[QUALITY].val = QUALITY_DEF;
 
return 0;
 }
@@ -6685,7 +6699,7 @@ static int sd_start(struct gspca_dev *gspca_dev)
/* create the JPEG header */
jpeg_define(sd->jpeg_hdr, gspca_dev->height, gspca_dev->width,
0x21);  /* JPEG 422 */
-   jpeg_set_qual(sd->jpeg_hdr, sd->quality);
+   jpeg_set_qual(sd->jpeg_hdr, sd->ctrls[QUALITY].val);
 
mode = gspca_dev->cam.cam_mode[gspca_dev->curr_mode].priv;
switch (sd->sensor) {
@@ -6893,29 +6907,35 @@ static int sd_querymenu(struct gspca_dev *gspca_dev,
return -EINVAL;
 }
 
-static int sd_set_jcomp(struct gspca_dev *gspca_dev,
-   struct v4l2_jpegcompression *jcomp)
+static int sd_setquality(struct gspca_dev *gspca_dev, __s32 val)
 {
struct sd *sd = (struct sd *) gspca_dev;
 
-   if (jcomp->quality < QUALITY_MIN)
-   sd->quality = QUALITY_MIN;
-   else if (jcomp->quality > QUALITY_MAX)
-   sd->quality = QUALITY_MAX;
-   else
-   sd->quality = jcomp->quality;
+   sd->ctrls[QUALITY].val = val;
+
if (gspca_dev->streaming)
-   jpeg_set_qual(sd->jpeg_hdr, sd->quality);
+   jpeg_set_qual(sd->jpeg_hdr, val);
+
return gspca_dev->usb_err;
 }
 
+static int sd_set_jcomp(struct gspca_dev *gspca_dev,
+   struct v4l2_jpegcompression *jcomp)
+{
+   struct sd *sd = (struct sd *) gspca_dev;
+
+   sd->ctrls[QUALITY].val = clamp_t(u8, jcomp->quality,
+   QUALITY_MIN, QUALITY_MAX);
+   return sd_setquality(gspca_dev, sd->ctrls[QUALITY].val);
+}
+
 static int sd_get_jcomp(struct gspca_dev *gspca_dev,
struct v4l2_jpegcompression *jcomp)
 {
struct sd *sd = (struct sd *) gspca_dev;
 
memset(jcomp, 0, sizeof *jcomp);
-   jcomp->quality = sd->quality;
+   jcomp->quality = sd->ctrls[QUALITY].val;
jcomp->jpeg_markers = V4L2_JPEG_MARKER_DHT
| V4L2_JPEG_MARKER_DQT;
return 0;
-- 
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/RFC v2 2/4] V4L: Add JPEG compression control class documentation

[Sylwester Nawrocki]

Add DocBook entries for the JPEG control class.

Signed-off-by: Sylwester Nawrocki 
---
 Documentation/DocBook/media/v4l/biblio.xml |   20 +++
 Documentation/DocBook/media/v4l/compat.xml |   10 ++
 Documentation/DocBook/media/v4l/controls.xml   |  161 
 Documentation/DocBook/media/v4l/v4l2.xml   |9 +
 .../DocBook/media/v4l/vidioc-g-jpegcomp.xml|   16 ++-
 5 files changed, 214 insertions(+), 2 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/biblio.xml 
b/Documentation/DocBook/media/v4l/biblio.xml
index cea6fd3..7dc65c5 100644
--- a/Documentation/DocBook/media/v4l/biblio.xml
+++ b/Documentation/DocBook/media/v4l/biblio.xml
@@ -128,6 +128,26 @@ 
url="http://www.ijg.org";>http://www.ijg.org)
   Version 1.02
 
 
+
+  ITU-T.81
+  
+   International Telecommunication Union
+(http://www.itu.int";>http://www.itu.int)
+  
+  ITU-T Recommendation T.81
+"Information Technology — Digital Compression and Coding of 
Continous-Tone
+Still Images — Requirements and Guidelines"
+
+
+
+  W3C JPEG JFIF
+  
+   The World Wide Web Consortium (http://www.w3.org/Graphics/JPEG";>http://www.w3.org)
+  
+  JPEG JFIF
+
+
 
   SMPTE 12M
   
diff --git a/Documentation/DocBook/media/v4l/compat.xml 
b/Documentation/DocBook/media/v4l/compat.xml
index 12ba262..1ac96db 100644
--- a/Documentation/DocBook/media/v4l/compat.xml
+++ b/Documentation/DocBook/media/v4l/compat.xml
@@ -2390,6 +2390,16 @@ that used it. It was originally scheduled for removal in 
2.6.35.
   
 
 
+
+  V4L2 in Linux 3.4
+  
+
+ Added JPEG compression control
+ class.
+
+  
+
+
 
   Relation of V4L2 to other Linux multimedia APIs
 
diff --git a/Documentation/DocBook/media/v4l/controls.xml 
b/Documentation/DocBook/media/v4l/controls.xml
index a1be378..b99f58b 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -3377,6 +3377,167 @@ interface and may change in the future.

   
   
+
+
+
+  JPEG Control Reference
+  The JPEG class includes controls for common features of JPEG
+  encoders and decoders. Currently it includes features for codecs
+  implementing progressive baseline DCT compression process with
+  Huffman entrophy coding.
+  
+  JPEG Control IDs
+
+  
+   
+   
+   
+   
+   
+   
+   
+ 
+   ID
+   Type
+ Description
+ 
+   
+   
+ 
+ 
+   V4L2_CID_JPEG_CLASS 
+   class
+ The JPEG class descriptor. Calling
+ &VIDIOC-QUERYCTRL; for this control will return a description of this
+ control class.
+
+   
+ 
+ 
+   V4L2_CID_JPEG_CHROMA_SUBSAMPLING
+   menu
+ 
+ 
+   The chroma subsampling factors describe how
+   each component of an input image is sampled, in respect to maximum
+   sample rate in each spatial dimension. See ,
+   clause A.1.1. for more details. The 
+   V4L2_CID_JPEG_CHROMA_SUBSAMPLING control determines how
+   Cb and Cr components are downsampled after coverting an input image
+   from RGB to Y'CbCr color space.
+   
+ 
+ 
+   
+ 
+   
+ V4L2_JPEG_CHROMA_SUBSAMPLING_444
+ No chroma subsampling, each pixel has
+ Y, Cr and Cb values.
+   
+   
+ V4L2_JPEG_CHROMA_SUBSAMPLING_422
+ Horizontally subsample Cr, Cb components
+ by a factor of 2.
+   
+   
+ V4L2_JPEG_CHROMA_SUBSAMPLING_420
+ Subsample Cr, Cb components horizontally
+ and vertically by 2.
+   
+   
+ V4L2_JPEG_CHROMA_SUBSAMPLING_411
+ Horizontally subsample Cr, Cb components
+ by a factor of 4.
+   
+   
+ V4L2_JPEG_CHROMA_SUBSAMPLING_410
+ Subsample Cr, Cb components horizontally
+ by 4 and vertically by 2.
+   
+   
+ V4L2_JPEG_CHROMA_SUBSAMPLING_GRAY
+ Use only luminance component.
+   
+ 
+   
+ 
+ 
+   V4L2_CID_JPEG_RESTART_INTERVAL
+   integer
+ 
+ 
+ The restart interval determines an interval of inserting RSTm
+ markers (m = 0..7). The purpose of these markers is to 
additionally
+ reinitialize the encoder process, in order to process blocks of
+ an image independently.
+ For the lossy compression processes the restart interval unit is
+

[PATCH/RFC v2 1/4] V4L: Add JPEG compression control class

[Sylwester Nawrocki]

The V4L2_CID_JPEG_CLASS control class is intended to expose various
adjustable parameters of JPEG encoders and decoders. Following controls
are defined:

 - V4L2_CID_JPEG_CHROMA_SUBSAMPLING,
 - V4L2_CID_JPEG_RESTART_INTERVAL,
 - V4L2_CID_JPEG_COMPRESSION_QUALITY,
 - V4L2_CID_JPEG_ACTIVE_MARKER.

This covers only a part of relevant standard specifications. More
controls should be added in future if required.

The purpose of V4L2_CID_JPEG_CLASS class is also to replace some
functionality covered by VIDIOC_S/G_JPEGCOMP ioctls, i.e. the JPEG
markers presence and compression quality control. The applications
and drivers should switch from the ioctl to control based API, as
described in the subsequent patches for the Media API DocBook.

Signed-off-by: Sylwester Nawrocki 
---
 drivers/media/video/v4l2-ctrls.c |   24 
 include/linux/videodev2.h|   24 
 2 files changed, 48 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index da1f4c2..1fd6435 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -353,6 +353,16 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
NULL,
};
 
+   static const char * const jpeg_chroma_subsampling[] = {
+   "4:4:4",
+   "4:2:2",
+   "4:2:0",
+   "4:1:1",
+   "4:1:0",
+   "Gray",
+   NULL,
+   };
+
switch (id) {
case V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ:
return mpeg_audio_sampling_freq;
@@ -414,6 +424,9 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return mpeg_mpeg4_level;
case V4L2_CID_MPEG_VIDEO_MPEG4_PROFILE:
return mpeg4_profile;
+   case V4L2_CID_JPEG_CHROMA_SUBSAMPLING:
+   return jpeg_chroma_subsampling;
+
default:
return NULL;
}
@@ -607,6 +620,14 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_FLASH_CHARGE: return "Charge";
case V4L2_CID_FLASH_READY:  return "Ready to strobe";
 
+   /* JPEG encoder controls */
+   /* Keep the order of the 'case's the same as in videodev2.h! */
+   case V4L2_CID_JPEG_CLASS:   return "JPEG Compression 
Controls";
+   case V4L2_CID_JPEG_CHROMA_SUBSAMPLING:  return "Chroma Subsampling";
+   case V4L2_CID_JPEG_RESTART_INTERVAL:return "Restart Interval";
+   case V4L2_CID_JPEG_COMPRESSION_QUALITY: return "Compression Quality";
+   case V4L2_CID_JPEG_ACTIVE_MARKER:   return "Active Markers";
+
default:
return NULL;
}
@@ -693,6 +714,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum 
v4l2_ctrl_type *type,
case V4L2_CID_MPEG_VIDEO_H264_VUI_SAR_IDC:
case V4L2_CID_MPEG_VIDEO_MPEG4_LEVEL:
case V4L2_CID_MPEG_VIDEO_MPEG4_PROFILE:
+   case V4L2_CID_JPEG_CHROMA_SUBSAMPLING:
*type = V4L2_CTRL_TYPE_MENU;
break;
case V4L2_CID_RDS_TX_PS_NAME:
@@ -704,6 +726,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum 
v4l2_ctrl_type *type,
case V4L2_CID_MPEG_CLASS:
case V4L2_CID_FM_TX_CLASS:
case V4L2_CID_FLASH_CLASS:
+   case V4L2_CID_JPEG_CLASS:
*type = V4L2_CTRL_TYPE_CTRL_CLASS;
/* You can neither read not write these */
*flags |= V4L2_CTRL_FLAG_READ_ONLY | V4L2_CTRL_FLAG_WRITE_ONLY;
@@ -717,6 +740,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum 
v4l2_ctrl_type *type,
*max = 0xFF;
break;
case V4L2_CID_FLASH_FAULT:
+   case V4L2_CID_JPEG_ACTIVE_MARKER:
*type = V4L2_CTRL_TYPE_BITMASK;
break;
case V4L2_CID_MIN_BUFFERS_FOR_CAPTURE:
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 2965906..a13fd34 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1080,6 +1080,7 @@ struct v4l2_ext_controls {
 #define V4L2_CTRL_CLASS_CAMERA 0x009a  /* Camera class controls */
 #define V4L2_CTRL_CLASS_FM_TX 0x009b   /* FM Modulator control class */
 #define V4L2_CTRL_CLASS_FLASH 0x009c   /* Camera flash controls */
+#define V4L2_CTRL_CLASS_JPEG 0x009d/* JPEG-compression 
controls */
 
 #define V4L2_CTRL_ID_MASK(0x0fff)
 #define V4L2_CTRL_ID2CLASS(id)((id) & 0x0fffUL)
@@ -1688,6 +1689,29 @@ enum v4l2_flash_strobe_source {
 #define V4L2_CID_FLASH_CHARGE  (V4L2_CID_FLASH_CLASS_BASE + 11)
 #define V4L2_CID_FLASH_READY   (V4L2_CID_FLASH_CLASS_BASE + 12)
 
+/*  JPEG-class control IDs defined by V4L2 */
+#define V4L2_CID_JPEG_CLASS_BASE   (V4L2_CTRL_CLASS_JPEG | 0x900)
+#define V4L2_CID_JPEG_CLASS(V4L2_CTRL_CLASS_JPEG | 1)
+
+#defineV4L2_CID_JPEG_CHROMA_SUBSAMP

[PATCH/RFC v2 0/4] JPEG codecs control class

[Sylwester Nawrocki]

Hello,

This patch set adds new control class - V4L2_CID_JPEG_CLASS with initially
four controls in it. It also adds V4L2_CID_JPEG_COMPRESSION_QUALITY control
to two gspca sub-devices: sonixj and zc3xx, as these where drivers I had
the hardware handy for. The gspca patches have been tested with v4l2ucp
and v4l2-ctl.

I could provide patches for some other drivers that currently use
VIDIOC_S/G_JPEGCOMP ioctls for image quality setting only.

The initial RFC can be found at
http://www.mail-archive.com/linux-media@vger.kernel.org/msg39012.html

Changes since v1 [1]:
 - renamed trailing 'S' from V4L2_CID_JPEG_ACTIVE_MARKERS;
 - removed V4L2_JPEG_ACTIVE_MARKER_DAC and V4L2_JPEG_ACTIVE_MARKER_DNL
   definitions as these are normally controlled by higher level compression
   attributes and shouldn't be allowed to be discarded independently;

These patches are intended for v3.4. Comments are welcome.


Sylwester Nawrocki (4):
  V4L: Add JPEG compression control class
  V4L: Add JPEG compression control class documentation
  gspca: sonixj: Add V4L2_CID_JPEG_COMPRESSION_QUALITY control support
  gspca: zc3xx: Add V4L2_CID_JPEG_COMPRESSION_QUALITY control support

 Documentation/DocBook/media/v4l/biblio.xml |   20 +++
 Documentation/DocBook/media/v4l/compat.xml |   10 ++
 Documentation/DocBook/media/v4l/controls.xml   |  161 
 Documentation/DocBook/media/v4l/v4l2.xml   |9 +
 .../DocBook/media/v4l/vidioc-g-jpegcomp.xml|   16 ++-
 drivers/media/video/gspca/sonixj.c |   23 +++
 drivers/media/video/gspca/zc3xx.c  |   54 +--
 drivers/media/video/v4l2-ctrls.c   |   24 +++
 include/linux/videodev2.h  |   24 +++
 9 files changed, 322 insertions(+), 19 deletions(-)

--
Thanks,
Sylwester

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

em28xx: no sound on board 1b80:e309 (sveon stv40)

[Mario Ceresa]

Hello again!

I managed to obtain a nice video input from my sveon usb stick using
last em28xx v4l drivers from git and giving the module the hint
card=19.

But I have no audio.The card works flawlessy in windows.

The internal chipsets in the card are:
- USB interface: em2860
- Audio ADC: emp202
- Video ADC: saa7118h (philips)

Attached is the relevant dmseg output.

The usb audio card card correctly shows in pulseaudio volume control
and is recognized as hw.2 by alsa:
$ arecord -l
 List of CAPTURE Hardware Devices 
card 0: Intel [HDA Intel], device 0: AD198x Analog [AD198x Analog]
  Subdevices: 3/3
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
card 2: STV40 [USB 2861 Device (SVEON STV40)], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

However, I'm not able to record any sound from it and mplayer says "no audio":
$ mplayer -tv 
device=/dev/video0:input=1:norm=PAL:alsa:immediatemode=0:audiorate=48000:amode=1:adevice=hw.2
tv://
MPlayer SVN-r33996-4.6.1 (C) 2000-2011 MPlayer Team
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.

Playing tv://.
TV file format detected.
Selected driver: v4l2
 name: Video 4 Linux 2 input
 author: Martin Olschewski 
 comment: first try, more to come ;-)
Selected device: EM2860/SAA711X Reference Design
 Capabilities:  video capture  VBI capture device  audio  read/write  streaming
 supported norms: 0 = NTSC; 1 = NTSC-M; 2 = NTSC-M-JP; 3 = NTSC-M-KR;
4 = NTSC-443; 5 = PAL; 6 = PAL-BG; 7 = PAL-H; 8 = PAL-I; 9 = PAL-DK;
10 = PAL-M; 11 = PAL-N; 12 = PAL-Nc; 13 = PAL-60; 14 = SECAM; 15 =
SECAM-B; 16 = SECAM-G; 17 = SECAM-H; 18 = SECAM-DK; 19 = SECAM-L; 20 =
SECAM-Lc;
 inputs: 0 = S-Video; 1 = Composite1;
 Current input: 1
 Current format: YUYV
v4l2: ioctl set format failed: Invalid argument
v4l2: ioctl set format failed: Invalid argument
v4l2: ioctl set format failed: Invalid argument
Selected input hasn't got a tuner!
==
Opening video decoder: [raw] RAW Uncompressed Video
Movie-Aspect is undefined - no prescaling applied.
VO: [vdpau] 640x480 => 640x480 Packed YUY2
Selected video codec: [rawyuy2] vfm: raw (RAW YUY2)
==
Audio: no sound
Starting playback...
V:   2.0  52/ 52  0%  5%  0.0% 0 0
v4l2: 59 frames successfully processed, 0 frames dropped.

Maybe has something to do with the last line in dmesg:

[  403.359333] ALSA sound/usb/mixer.c:845 2:1: cannot get min/max
values for control 2 (id 2)

Any ideas?

Mario
[  389.491488] Linux video capture interface: v2.00
[  389.491490] WARNING: You are using an experimental version of the media 
stack.
[  389.491491]  As the driver is backported to an older kernel, it doesn't offer
[  389.491491]  enough quality for its usage in production.
[  389.491492]  Use it with care.
[  389.491492] Latest git patches (needed if you report a bug to 
linux-media@vger.kernel.org):
[  389.491493]  1e73fa5d56333230854ae9460579eb2fcee8af02 [media] stb6100: 
Properly retrieve symbol rate
[  389.491494]  e97a5d893fdf45c20799b72a1c11dca3b282c89c [media] 
fs/compat_ioctl: it needs to see the DVBv3 compat stuff
[  389.491495]  53c91373bdd74f7e11d2726046a90b986c1ed650 [media] dvb: remove 
the extra parameter on get_frontend
[  389.518213] usbcore: registered new interface driver em28xx
[  389.518215] em28xx driver loaded
[  401.754076] usb 1-5.3: new high speed USB device number 4 using ehci_hcd
[  401.844655] usb 1-5.3: New USB device found, idVendor=1b80, idProduct=e309
[  401.844658] usb 1-5.3: New USB device strings: Mfr=0, Product=1, 
SerialNumber=0
[  401.844660] usb 1-5.3: Product: USB 2861 Device (SVEON STV40)
[  401.845694] em28xx: New device USB 2861 Device (SVEON STV40) @ 480 Mbps 
(1b80:e309, interface 0, class 0)
[  401.845828] em28xx #0: chip ID is em2860
[  401.947993] em28xx #0: i2c eeprom 00: 1a eb 67 95 80 1b 09 e3 50 00 20 03 6a 
3c 00 00
[  401.948000] em28xx #0: i2c eeprom 10: 00 00 04 57 06 02 00 00 00 00 00 00 00 
00 00 00
[  401.948005] em28xx #0: i2c eeprom 20: 02 00 01 00 f0 00 01 00 00 00 00 00 5b 
00 00 00
[  401.948010] em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 01 01 02 01 00 
00 00 00
[  401.948015] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00
[  401.948020] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00
[  401.948025] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 3c 03 55 
00 53 00
[  401.948030] em28xx #0: i2c eeprom 70: 42 00 20 00 32 00 38 00 36 00 31 00 20 
00 44 00
[  401.948035] em28xx #0: i2c eeprom 80: 65 00 76 00 69 00 63 00 65 00 20 00 28 
00 53 00
[  401.948040] em28xx #0: i2c eeprom 90: 56 00 45 00 4f 00 4e 00 20 00 53 00 54 
00 56 00
[  401.948045] em28xx #0: i2c eeprom a0: 34 00 30 00 29 00 00 00 00 00 00 00 00 
00 00 00
[

Re: sveon stv40 usb stick

[Mario Ceresa]

Last updates. It works with em28xx module from v4l git as a card 19:
# modprobe em28xx card=19
# echo 1b80 e309 > /sys/bus/usb/drivers/em28xx/new_id

[plugged in the usb] and

$ mplayer -tv 
device=/dev/video0:input=1:norm=PAL:alsa:immediatemode=0:audiorate=48000:amode=1:adevice=hw.2
tv://

But I have no audio... I will open a new thread only for the audio problem!

Best,
Mario


On 6 January 2012 15:52, Mario Ceresa  wrote:
> Hi again!
>
> following the thread "em28xx: new board id [eb1a:5051]" between Reuben
> and Gareth I was able to advance a little:
>
> 1) I opened the usn stick and my chipsets are:
> - USB interface: em2860
> - Audio ADC: emp202
> - Video ADC: saa7118h (philips)
>
> 2) I confirm that the stock em28xx driver can recognize the usb stick
> but needs to specify a card manually as an option.
>
> 3) Using "modprobe em18xx card=19" (which corresponds to
> "EM2860/SAA711X Reference Design") I can go so far as to get a
> /dev/video0, but the preview is black no matter what i do.
>
> 4) I was able to eventually compile the v4l drivers but, as soon as I
> inject the driver, I get a kernel oops (attached). I made no change to
> the code obtained with git.
>
> I won't even mind to write some code myself, but I really have no idea
> where to begin with!
>
> Thanks in advance for any help you might provide,
>
> Best,
>
> Mario
>
>
>
> On 3 January 2012 20:44, Mario Ceresa  wrote:
>> Hello everybody!
>> I recently bougth a Sveon STV40 usb stick to capture analogic video
>> (http://www.sveon.com/fichaSTV40.html)
>> I can use it in windows but my linux box (Fedora 16 -
>> 3.1.6-1.fc16.x86_64 - gcc 4.6.2) can't recognize it.
>> Is there any way I can fix this?
>>
>> These are the results of my investigation so far:
>>
>> 1) It is identified by lsusb as an Afatech board (1b80:e309) with an
>> Empia 2861 chip (from dmesg and windows driver inf file)
>> 2) I experimented with em28xx  because the chipset was empia and with
>> af9015 because I found that the stv22 was supported
>> (http://linuxtv.org/wiki/index.php/Afatech_AF9015). In both cases
>> after I manually added the vendor:id to /sys/bus/usb/drivers/ driver
>> started but in the end I was not able to succeed. With em28xx I could
>> go as far as having a /dev/video0 device but with no signal and the
>> dmesg log said to ask here for help :) . With the af9015 I had an
>> early stop.
>> 3) Both the logs are attached.
>> 4) I used the driver shipped with the fedora stock kernel because I
>> can't compile the ones that I get from
>> git://linuxtv.org/media_build.git. I have an error at:
>>
>> CC [M]  media_build/v4l/as3645a.o
>> media_build/v4l/as3645a.c: In function 'as3645a_probe':
>> media_build/v4l/as3645a.c:815:2: error: implicit declaration of
>> function 'kzalloc' [-Werror=implicit-function-declaration]
>> media_build/v4l/as3645a.c:815:8: warning: assignment makes pointer
>> from integer without a cast [enabled by default]
>> cc1: some warnings being treated as errors
>>
>> Thank you in advance for any help you might provide on this issue!
>>
>> ,Best regards
>>
>> Mario
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 16/17] smiapp: Add driver.

[Sylwester Nawrocki]

Hi Sakari,

I have a just a few comments below. It was rather brief a review, given the
size of the patch.. :-)

On 12/20/2011 09:28 PM, Sakari Ailus wrote:
> Add driver for SMIA++/SMIA image sensors. The driver exposes the sensor as
> three subdevs, pixel array, binner and scaler --- in case the device has a
> scaler.
> 
> Currently it relies on the board code for external clock handling. There is
> no fast way out of this dependency before the ISP drivers (omap3isp) among
> others will be able to export that clock through the clock framework
> instead.
> 
> Signed-off-by: Sakari Ailus
> ---
>   drivers/media/video/Kconfig   |   13 +
>   drivers/media/video/Makefile  |3 +
>   drivers/media/video/smiapp-core.c | 2595 
> +
>   drivers/media/video/smiapp-debug.h|   32 +
>   drivers/media/video/smiapp-limits.c   |  132 ++
>   drivers/media/video/smiapp-limits.h   |  128 ++
>   drivers/media/video/smiapp-pll.c  |  664 +
>   drivers/media/video/smiapp-quirk.c|  264 
>   drivers/media/video/smiapp-quirk.h|   72 +
>   drivers/media/video/smiapp-reg-defs.h |  733 ++
>   drivers/media/video/smiapp-reg.h  |  119 ++
>   drivers/media/video/smiapp-regs.c |  222 +++
>   drivers/media/video/smiapp.h  |  250 
>   include/media/smiapp-regs.h   |   51 +
>   include/media/smiapp.h|   82 +
>   15 files changed, 5360 insertions(+), 0 deletions(-)
>   create mode 100644 drivers/media/video/smiapp-core.c
>   create mode 100644 drivers/media/video/smiapp-debug.h
>   create mode 100644 drivers/media/video/smiapp-limits.c
>   create mode 100644 drivers/media/video/smiapp-limits.h
>   create mode 100644 drivers/media/video/smiapp-pll.c
>   create mode 100644 drivers/media/video/smiapp-quirk.c
>   create mode 100644 drivers/media/video/smiapp-quirk.h
>   create mode 100644 drivers/media/video/smiapp-reg-defs.h
>   create mode 100644 drivers/media/video/smiapp-reg.h
>   create mode 100644 drivers/media/video/smiapp-regs.c
>   create mode 100644 drivers/media/video/smiapp.h

How about creating new directory, e.g. drivers/media/video/smiapp/ ? 

>   create mode 100644 include/media/smiapp-regs.h
>   create mode 100644 include/media/smiapp.h
> 
> diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
> index 4e8a0c4..0aa8f13 100644
> --- a/drivers/media/video/Kconfig
> +++ b/drivers/media/video/Kconfig
> @@ -524,6 +524,19 @@ config VIDEO_S5K6AA
> This is a V4L2 sensor-level driver for Samsung S5K6AA(FX) 1.3M
> camera sensor with an embedded SoC image signal processor.
> 
> +config VIDEO_SMIAPP
> + tristate "SMIA++/SMIA sensor support"
> + depends on I2C&&  VIDEO_V4L2

There is no dependency on VIDEO_V4L2_SUBDEV_API ?

> + ---help---
> +   This is a generic driver for SMIA++/SMIA camera modules.
> +
> +config VIDEO_SMIAPP_DEBUG
> + bool "Enable debugging for the generic SMIA++/SMIA driver"
> + depends on VIDEO_SMIAPP
> + ---help---
> +   Enable debugging output in the generic SMIA++/SMIA driver. If you
> +   are developing the driver you might want to enable this.
> +
>   comment "Flash devices"
> 
>   config VIDEO_ADP1653
> diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
> index ddeaa6c..82a0cea 100644
> --- a/drivers/media/video/Makefile
> +++ b/drivers/media/video/Makefile
> @@ -73,6 +73,9 @@ obj-$(CONFIG_VIDEO_SR030PC30)   += sr030pc30.o
>   obj-$(CONFIG_VIDEO_NOON010PC30) += noon010pc30.o
>   obj-$(CONFIG_VIDEO_M5MOLS)  += m5mols/
>   obj-$(CONFIG_VIDEO_S5K6AA)  += s5k6aa.o
> +smiapp-objs  += smiapp-core.o smiapp-regs.o smiapp-pll.o \
> +smiapp-quirk.o smiapp-limits.o
> +obj-$(CONFIG_VIDEO_SMIAPP)   += smiapp.o
>   obj-$(CONFIG_VIDEO_ADP1653) += adp1653.o
> 
>   obj-$(CONFIG_SOC_CAMERA_IMX074) += imx074.o
> diff --git a/drivers/media/video/smiapp-core.c 
> b/drivers/media/video/smiapp-core.c
> new file mode 100644
> index 000..1d15c1d
> --- /dev/null
> +++ b/drivers/media/video/smiapp-core.c
> @@ -0,0 +1,2595 @@
> +/*
> + * drivers/media/video/smiapp-core.c
> + *
> + * Generic driver for SMIA/SMIA++ compliant camera modules
> + *
> + * Copyright (C) 2010--2011 Nokia Corporation
> + * Contact: Sakari Ailus
> + *
> + * Based on smiapp driver by Vimarsh Zutshi
> + * Based on jt8ev1.c by Vimarsh Zutshi
> + * Based on smia-sensor.c by Tuukka Toivonen
> + *
> + * 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 receive

Re: Broken ioctl error returns (was Re: [PATCH 2/3] block: fail SCSI passthrough ioctls on partition devices)

[Linus Torvalds]

On Fri, Jan 6, 2012 at 8:19 AM, Arnd Bergmann  wrote:
>
> For a simpler solution, we could keep the old warning message, but change
> the logic from
>
> (.compat_ioctl == NULL || .compat_ioctl() == -ENOIOCTL) && (no generic 
> handler)
>
> to
>
> (.ioctl != NULL && .compat_ioctl == NULL) && (no generic handler).
>
> and then fix the warnings we see by adding appropriate .compat_ioctl
> functions.

So I have no problem with that. What I did have problems with was the
net/socket.c kind of workarounds (which I noticed mainly because they
had that whole EINVAL confusion built into them). Those were why I
decided that the warning has to go.

But if you can re-introduce the warning without workarounds like
those, I have no problem with us reintroducing the warning, even if it
is technically not really kosher and will afaik still print that
warning for the case of a compat-ioctl transform that *would* have
been valid, just not for that particular file descriptor.

But the printout is small and not all that annoying, and explicitly
limited in number, so I guess I don't mind a few false positives if it
really can help find stale translation entries.

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

[PATCH] [media] flexcop: CodingStyle fix: don't use "if ((ret = foo()) < 0)"

[Jonathan Nieder]

Lift assignments from "if" conditionals for readability.  No change
in functionality intended.

Suggested-by: Mauro Carvalho Chehab 
Signed-off-by: Jonathan Nieder 
---
Mauro Carvalho Chehab wrote:

> Subject: [media] flexcop: handle errors from dvb_net_init
[...]
> [mche...@redhat.com: CodingStyle fix: don't use  "if ((ret = foo()) < 0)"]

Here's a patch to take care of the other instances of that construct
in the same file.

 drivers/media/dvb/b2c2/flexcop.c |   21 ++---
 1 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/drivers/media/dvb/b2c2/flexcop.c b/drivers/media/dvb/b2c2/flexcop.c
index 4d3caca466fd..b1e8c99f469b 100644
--- a/drivers/media/dvb/b2c2/flexcop.c
+++ b/drivers/media/dvb/b2c2/flexcop.c
@@ -86,7 +86,8 @@ static int flexcop_dvb_init(struct flexcop_device *fc)
fc->demux.stop_feed = flexcop_dvb_stop_feed;
fc->demux.write_to_decoder = NULL;
 
-   if ((ret = dvb_dmx_init(&fc->demux)) < 0) {
+   ret = dvb_dmx_init(&fc->demux);
+   if (ret < 0) {
err("dvb_dmx failed: error %d", ret);
goto err_dmx;
}
@@ -96,23 +97,27 @@ static int flexcop_dvb_init(struct flexcop_device *fc)
fc->dmxdev.filternum = fc->demux.feednum;
fc->dmxdev.demux = &fc->demux.dmx;
fc->dmxdev.capabilities = 0;
-   if ((ret = dvb_dmxdev_init(&fc->dmxdev, &fc->dvb_adapter)) < 0) {
+   ret = dvb_dmxdev_init(&fc->dmxdev, &fc->dvb_adapter);
+   if (ret < 0) {
err("dvb_dmxdev_init failed: error %d", ret);
goto err_dmx_dev;
}
 
-   if ((ret = fc->demux.dmx.add_frontend(&fc->demux.dmx, 
&fc->hw_frontend)) < 0) {
+   ret = fc->demux.dmx.add_frontend(&fc->demux.dmx, &fc->hw_frontend);
+   if (ret < 0) {
err("adding hw_frontend to dmx failed: error %d", ret);
goto err_dmx_add_hw_frontend;
}
 
fc->mem_frontend.source = DMX_MEMORY_FE;
-   if ((ret = fc->demux.dmx.add_frontend(&fc->demux.dmx, 
&fc->mem_frontend)) < 0) {
+   ret = fc->demux.dmx.add_frontend(&fc->demux.dmx, &fc->mem_frontend);
+   if (ret < 0) {
err("adding mem_frontend to dmx failed: error %d", ret);
goto err_dmx_add_mem_frontend;
}
 
-   if ((ret = fc->demux.dmx.connect_frontend(&fc->demux.dmx, 
&fc->hw_frontend)) < 0) {
+   ret = fc->demux.dmx.connect_frontend(&fc->demux.dmx, &fc->hw_frontend);
+   if (ret < 0) {
err("connect frontend failed: error %d", ret);
goto err_connect_frontend;
}
@@ -260,7 +265,8 @@ int flexcop_device_initialize(struct flexcop_device *fc)
flexcop_hw_filter_init(fc);
flexcop_smc_ctrl(fc, 0);
 
-   if ((ret = flexcop_dvb_init(fc)))
+   ret = flexcop_dvb_init(fc);
+   if (ret)
goto error;
 
/* i2c has to be done before doing EEProm stuff -
@@ -278,7 +284,8 @@ int flexcop_device_initialize(struct flexcop_device *fc)
} else
warn("reading of MAC address failed.\n");
 
-   if ((ret = flexcop_frontend_init(fc)))
+   ret = flexcop_frontend_init(fc);
+   if (ret)
goto error;
 
flexcop_device_name(fc,"initialization of","complete");
-- 
1.7.8.2

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

[PATCH] rc-videomate-m1f.c Rename to match remote controler name

[Samuel Rakitničan]

This remote was added with support for card Compro VideoMate M1F.

This remote is shipped with various Compro cards, not this one only.

Furthermore this remote can be bought separately under name Compro
VideoMate K100.
http://compro.com.tw/en/product/k100/k100.html

So give it a proper name.


Signed-off-by: Samuel Rakitničan 

k100.diff
Description: Binary data

Re: Broken ioctl error returns (was Re: [PATCH 2/3] block: fail SCSI passthrough ioctls on partition devices)

[Arnd Bergmann]

On Thursday 05 January 2012, Linus Torvalds wrote:

> And finally, ENOIOCTLCMD is a way to say ENOTTY in a sane manner, and
> will now be turned into ENOTTY for the user space return (not EINVAL -
> I have no idea where that idiocy came from, but it's clearly confused,
> although it's also clearly very old).

To give some background here: While I did a lot of changes to the
compat ioctl code over the years, I never touched the EINVAL/ENOTTY
logic out of fear of breaking things further. Your patch is probably
the right answer here and we should have done it long ago.

> This fixes the core files I noticed. It removes the insane
> complaints from the compat_ioctl() (which would complain if you
> returned ENOIOCTLCMD after an ioctl translation - the reason that is
> totally insane is that somebody might use an ioctl on the wrong kind
> of file descriptor, so even if it was translated perfectly fine,
> ENOIOCTLCMD is a perfectly fine error return and shouldn't cause
> warnings - and that allows us to remove stupid crap from the socket
> ioctl code).

Now this behavior was entirely intentional. ENOIOCTLCMD was introduced
explicitly so we could tell the difference between compat_ioctl handlers
saying "I don't know how to translate this but common code might know"
(ENOIOCTLCMD) and "I know that this is not a valid command code here"
(ENOTTY plus whatever a broken driver might return).

The distinction is used in two places:

1. To let device drivers return early from fops->compat_ioctl when
they want to avoid the overhead from searching the COMPATIBLE_IOCTL()
table and from the (formerly large) switch statement in do_ioctl_trans(),
or when they want to make sure that the common translation is not
called. We have some really tricky bits in the socket code where
the crazy SIOCDEVPRIVATE needs to be handled specially by some drivers
while the majority can use the default siocdevprivate_ioctl() function.

2. To return from do_ioctl_trans() when we know that there is no
translation for the command number, so that the we can write a warning
to the console (which you have now removed). This was initially more
useful back when do_ioctl_trans() knew about practically all command
numbers, but we have gradually moved all handlers into device drivers
where they belong, and that has caused the problem that we get warnings
whenever a user attempts an ioctl on a device that does not handle the
command even when all the correct devices that support the command also
have a compat handler. The common way we handle those is to add an
IGNORE_IOCTL() entry for a command that repeatedly shows up in logs
that way and is known to be handled correctly.

I used to have patches to completely remove the remains of do_ioctl_trans()
that can be resurrected if that helps, but it's mostly an independent
issue.

While I agree that the existing compat_ioctl_error() method was somewhat
broken, I'd like to keep having a way to get some indication from
drivers that are missing ioctl translations. Ideally, we would move
all of fs/compat_ioctl.c into drivers and then just warn when we register
some file_operations on a 64 bit machine that have an ioctl but no
compat_ioctl function, but that would be a large amount of work.

For a simpler solution, we could keep the old warning message, but change
the logic from

(.compat_ioctl == NULL || .compat_ioctl() == -ENOIOCTL) && (no generic handler)

to

(.ioctl != NULL && .compat_ioctl == NULL) && (no generic handler).

and then fix the warnings we see by adding appropriate .compat_ioctl
functions.

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

Re: [PATCHv4 1/2] v4l: Add new framesamples field to struct v4l2_mbus_framefmt

[Sakari Ailus]

Hi Sylwester,

On Wed, Jan 04, 2012 at 11:51:00PM +0100, Sylwester Nawrocki wrote:
> On 01/04/2012 01:21 PM, Sakari Ailus wrote:
> > On Sun, Jan 01, 2012 at 07:56:03PM +0100, Sylwester Nawrocki wrote:
> >> On 12/31/2011 02:16 PM, Sakari Ailus wrote:
> > Something else that should probably belong there is information on the 
> > frame
> > format: contrary to what I've previously thought, the sensor metadata is
> > often sent as part of the same CSI-2 channel. There also can be other 
> > types
> > of data, such as dummy data and data for black level calibration. I 
> > wouldn't
> > want to export all this to the user space --- it shouldn't probably 
> > need to
> > care about it.
> >
> > The transmitter of the data (sensor) has this information and the CSI-2
> > receiver needs it. Same for the framesamples, as far as I understand.
> 
>  We could try to design some standard data structure for frame metadata -
>  that's how I understood the meaning of struct v4l2_mbus_framedesc.
>  But I doubt such attempts will be sucessful. And how can we distinguish
>  which data is valid and applicable when there is lots of weird stuff in 
>  one
>  data structure ? Using media bus pixel code only ?
> >>>
> >>> I think the media bus pixel code which is exported to the user space 
> >>> should
> >>> not be involved with the metadata.
> >>
> >> Then we need to find some method to distinguish streams with metadata on 
> >> the
> >> media bus, to be able to discard it before sending to user space.
> >> I assume this is where struct v4l2_mbus_framedesc and related ops would 
> >> help ?
> > 
> > I'd think so.
> > 
> >> Maybe we could create v4l2_mbus_framedesc with length (framesamples) member
> >> in it and additionally 994 reserved bytes for future extensions ;-), e.g.
> >>
> >> struct v4l2_mbus_framedesc {
> >>unsigned int length;
> >>unsigned int rserved[994];
> >> };
> > 
> > Do we need to export this to the user space? In the first phase I'd like to
> 
> No, that wasn't my intention. The reserved field was supposed to be a joke,
> we of course don't need any reserved members in the kernel space.

Oh, I have to admit I missed the joke completely. ;)

> > keep that static (i.e. only get op would be supported) and only visible in
> > the kernel. That would leave much more room for changes later on, if needed.
> 
> I'd prefer it to be R/W, i.e. having both get and set ops available. Maybe
> not for all fields though.

I guess we should gather all the requirements and write and RFC based on the
findings. I know at least about three different scenarios:

- metadata as part of the image, receiver writes it to the same buffer,
- metadata as part of the image, receiver writes it to a different buffer and
- metadata arriver through a separate csi or ccp2 channel

All may include metadata at bottom and / or top of the image.

> >> struct v4l2_subdev_pad_ops {
> >>  
> >>int get_framedesc(int pad, struct v4l2_framedesc *fdesc);
> >>int set_framedesc(int pad, struct v4l2_framedesc fdesc);
> >> };
> >>
> >> This would ensure same media bus format code regardless of frame meta data
> >> presence.
> >>
> >> In case metadata is sent in same CSI channel, the required buffer length
> >> might be greater than what would width/height and pixel code suggest.
> > 
> > Partly for this reason we have g_skip_top_lines() op in sensor ops. It
> > instructs the receiver to discard the metadata, and possibly other data
> > which isn't as interesting --- could be just dummy.
> 
> I see.
> 
> > Some CSI-2 receivers are able to write this to a different memory location;
> > we could expose this as a different video node. I'm proposing a different
> > video node since this is a separate queue: the format (in-memory pixel
> > format and dimensions) is different, and it is beneficial to have access to
> > this data as soon as possible. There is a caveat, though, if we also wish to
> > support metadata which is appended to the frame, rather than prependeded.
> 
> I think it is recurring topic in our discussions, I guess nobody really needs
> it since it haven't been implemented yet. ;)

It is needed, especially if you have camera control algorithms in the user
space. You can get around it in some cases, but the end result isn't pretty
nor reliable.

> Multi-planar buffers were meant also for handling meta data, only variable
> number of planes support would need to be added. For instance the driver could
> pass only the buffer with meta data plane if required.

Multi-planar buffers are definitely a part of the solution when the metadata
is part of the same memory buffer.

What I think would be needed is separation of pixel formats of different
planes: we do not want to create new pixel format out of every possible
combination of metadata and pixel format.

> >>> The metadata is something that the user is likely interested only in the
> >>> form it is in t

Re: em2874 bulk endpoint support

[Frank Schäfer]

Am 06.01.2012 01:52, schrieb Devin Heitmueller:

On Thu, Jan 5, 2012 at 6:16 PM, Dmitriy Fitisov  wrote:

Hello everyone,
I know, Devin Heitmueller was about to add support  for em2874 bulk endpoint.

Is that still in plans?

The project that I was slated to do this work for got cancelled, and
the only device I know of that requires bulk support is an obscure
K-world product.  It just didn't make any sense to waste the time for
one unpopular stick.


The Speedlink webcam "Vicious And Devine - Laplace" (em2765) would 
require bulk support, too:


http://www.vicious-and-divine.com/vicious/laplace.html
http://linuxtv.org/wiki/index.php/VAD_Laplace

Regards,
Frank

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

[PULL] git://git.kernellabs.com/stoth/cx23885-hvr1850-fixups.git

[Steven Toth]

Mauro,

Some changes to allow the querying of the NO_SIGNAL status feature on
the cx25840 video decoder.

The following changes since commit 45447e1e18131590203dba83f9044d6c48448e54:
  [media] cx25840: Added g_std support to the video decoder driver
(2012-01-04 19:16:15 -0500)
are available in the git repository at:
git://git.kernellabs.com/stoth/cx23885-hvr1850-fixups.git
staging/for_v3.3
Steven Toth (2):      [media] cx25840: Add support for g_input_status
    [media] cx23885: Query the CX25840 during enum_input for status
 drivers/media/video/cx23885/cx23885-video.c |    9 +
drivers/media/video/cx25840/cx25840-core.c  |   16  2
files changed, 25 insertions(+), 0 deletions(-)
Many thanks,

- Steve

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

Re: [RFC 17/17] rm680: Add camera init

[Sylwester Nawrocki]

Hi Sakari,

On 12/20/2011 09:28 PM, Sakari Ailus wrote:

+
+static int rm680_sec_camera_set_xshutdown(struct v4l2_subdev *subdev, u8 set)


It may be more efficient to just use u32.


+{
+   gpio_set_value(SEC_CAMERA_RESET_GPIO, !!set);
+   return 0;
+}
+

...

+void __init rm680_camera_init(void)
+{
+   struct isp_platform_data *pdata;
+   int rval;
+
+   rval = rm680_camera_hw_init();
+   if (rval) {
+   printk(KERN_WARNING "%s: unable to initialise camera\n",


pr_warn is preferred for new code.


+  __func__);
+   return;
+   }
+
+   if (board_is_rm680())
+   pdata =&rm680_isp_platform_data;
+   else
+   pdata =&rm696_isp_platform_data;
+
+   if (omap3_init_camera(pdata)<  0)
+   printk(KERN_WARNING


pr_warn


+  "%s: unable to register camera platform device\n",
+  __func__);
+}

...

+static struct regulator_consumer_supply rm680_vaux2_consumers[] = {
+   REGULATOR_SUPPLY("VDD_CSIPHY1", "omap3isp"),/* OMAP ISP */
+   REGULATOR_SUPPLY("VDD_CSIPHY2", "omap3isp"),/* OMAP ISP */
+   {
+   .supply = "vaux2",
+   },


Could also be
REGULATOR_SUPPLY("vaux2", NULL),


+};
+REGULATOR_INIT_DATA_FIXED(rm680_vaux2, 180);
+
+static struct regulator_consumer_supply rm680_vaux3_consumers[] = {
+   REGULATOR_SUPPLY("VANA", "2-0037"), /* Main Camera Sensor */
+   REGULATOR_SUPPLY("VANA", "2-000e"), /* Main Camera Lens */
+   REGULATOR_SUPPLY("VANA", "2-0010"), /* Front Camera */
+   {
+   .supply = "vaux3",
+   },


and REGULATOR_SUPPLY("vaux3", NULL),


+};


--
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 FOR 3.3] VIDIOC_LOG_STATUS support for sub-devices

[Sylwester Nawrocki]

On 01/06/2012 03:38 PM, Mauro Carvalho Chehab wrote:

On 31-12-2011 09:15, Sylwester Nawrocki wrote:

Hi Mauro,

The following changes since commit 3220eb73c5647af4c1f18e32c12dccb8adbac59d:

   s5p-fimc: Add support for alpha component configuration (2011-12-20 19:46:55
+0100)

are available in the git repository at:
   git://git.infradead.org/users/kmpark/linux-samsung v4l_mbus

This one patch enables VIDIOC_LOG_STATUS on subdev nodes.

Sylwester Nawrocki (1):
   v4l: Add VIDIOC_LOG_STATUS support for sub-device nodes



Weird... when trying to pull from your tree, several other patches appeared.
After removing the ones that seemed to be already applied, there are still
those that seemed to still apply:

Nov,17 2011: s5p-fimc: Prevent lock up caused by incomplete H/W initialization


This one was already requested in my previous pull request:
http://patchwork.linuxtv.org/patch/8765/


Oct, 1 2011: v4l: Add VIDIOC_LOG_STATUS support for sub-device nodes


and this is the only one new I'd like you to apply for 3.3.


Dec, 9 2011: v4l: Add new framesamples field to struct v4l2_mbus_framefmt
Dec,15 2011: v4l: Update subdev drivers to handle framesamples parameter
Dec,12 2011: m5mols: Add buffer size configuration support for compressed 
streams
Nov,21 2011: s5p-fimc: Add media bus framesamples support


These are irrelevant and should be dropped. Sorry for the confusion, 
I've sent this pull request when I didn't have write access to the

git://git.infradead.org/users/kmpark/linux-samsung repository.



Could you please double-check and, if possible, rebase your tree, to avoid
the risk of applying something that is not ok yet, nor to miss something?


Unfortunately I can't rebase at this moment, could do it only on Monday.
If possible please apply only:

 s5p-fimc: Prevent lock up caused by incomplete H/W initialization
 v4l: Add VIDIOC_LOG_STATUS support for sub-device nodes

for 3.3 and drop the bottom four.

--
Thank you,
Sylwester


Thanks!
Mauro

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

Re: [PATCH 9/9] [media] firedtv: handle errors from dvb_net_init

[Mauro Carvalho Chehab]

On 31-12-2011 10:19, Jonathan Nieder wrote:
> It is not common for dvb_net_init to fail, but after the patch
> "dvb_net_init: return -errno on error" it can fail due to running out
> of memory.  Handle this.
> 
>>From an audit of dvb_net_init callers.
> 
> Signed-off-by: Jonathan Nieder 
> ---
> That's the end of the series, though it would have been nice to
> also check the error handling in
> 
>  dvb/mantis/mantis_dvb.c
>  dvb/ngene/ngene-core.c (which looks a little strange)
>  dvb/pluto2/pluto2.c
>  dvb/pt1/pt1.c
>  dvb/ttpci/av7110.c 
>  dvb/ttpci/budget-core.c
>  dvb/ttusb-dec/ttusb_dec.c
>  video/au0828/au0828-dvb.c
>  video/cx18/cx18-dvb.c
>  video/cx231xx/cx231xx-dvb.c
>  video/em28xx/em28xx-dvb.c
>  video/pvrusb2/pvrusb2-dvb.c
>  video/saa7164/saa7164-dvb.c

It would be good if you could take a look on them and send us patches
for them if needed ;)

> 
> Hopefully this gives the idea, anyway.  Patch 2 is the important one,
> and the patches after that are just toys to show off patch 1.
> 
> Warning: the patches are _completely_ _untested_.  Test results
> (perhaps from provoking artificial failures in dvb_net_init), just
> like other comments, would be very welcome.
> 
> 'night,
> Jonathan
> 
>  drivers/media/dvb/firewire/firedtv-dvb.c |5 -
>  1 files changed, 4 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/media/dvb/firewire/firedtv-dvb.c 
> b/drivers/media/dvb/firewire/firedtv-dvb.c
> index fd8bbbfa5c59..eb7496eab130 100644
> --- a/drivers/media/dvb/firewire/firedtv-dvb.c
> +++ b/drivers/media/dvb/firewire/firedtv-dvb.c
> @@ -203,7 +203,9 @@ int fdtv_dvb_register(struct firedtv *fdtv, const char 
> *name)
>   if (err)
>   goto fail_rem_frontend;
>  
> - dvb_net_init(&fdtv->adapter, &fdtv->dvbnet, &fdtv->demux.dmx);
> + err = dvb_net_init(&fdtv->adapter, &fdtv->dvbnet, &fdtv->demux.dmx);
> + if (err)
> + goto fail_disconnect_frontend;
>  
>   fdtv_frontend_init(fdtv, name);
>   err = dvb_register_frontend(&fdtv->adapter, &fdtv->fe);
> @@ -218,6 +220,7 @@ int fdtv_dvb_register(struct firedtv *fdtv, const char 
> *name)
>  
>  fail_net_release:
>   dvb_net_release(&fdtv->dvbnet);
> +fail_disconnect_frontend:
>   fdtv->demux.dmx.close(&fdtv->demux.dmx);
>  fail_rem_frontend:
>   fdtv->demux.dmx.remove_frontend(&fdtv->demux.dmx, &fdtv->frontend);

--
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: sveon stv40 usb stick

[Mario Ceresa]

Hi again!

following the thread "em28xx: new board id [eb1a:5051]" between Reuben
and Gareth I was able to advance a little:

1) I opened the usn stick and my chipsets are:
- USB interface: em2860
- Audio ADC: emp202
- Video ADC: saa7118h (philips)

2) I confirm that the stock em28xx driver can recognize the usb stick
but needs to specify a card manually as an option.

3) Using "modprobe em18xx card=19" (which corresponds to
"EM2860/SAA711X Reference Design") I can go so far as to get a
/dev/video0, but the preview is black no matter what i do.

4) I was able to eventually compile the v4l drivers but, as soon as I
inject the driver, I get a kernel oops (attached). I made no change to
the code obtained with git.

I won't even mind to write some code myself, but I really have no idea
where to begin with!

Thanks in advance for any help you might provide,

Best,

Mario



On 3 January 2012 20:44, Mario Ceresa  wrote:
> Hello everybody!
> I recently bougth a Sveon STV40 usb stick to capture analogic video
> (http://www.sveon.com/fichaSTV40.html)
> I can use it in windows but my linux box (Fedora 16 -
> 3.1.6-1.fc16.x86_64 - gcc 4.6.2) can't recognize it.
> Is there any way I can fix this?
>
> These are the results of my investigation so far:
>
> 1) It is identified by lsusb as an Afatech board (1b80:e309) with an
> Empia 2861 chip (from dmesg and windows driver inf file)
> 2) I experimented with em28xx  because the chipset was empia and with
> af9015 because I found that the stv22 was supported
> (http://linuxtv.org/wiki/index.php/Afatech_AF9015). In both cases
> after I manually added the vendor:id to /sys/bus/usb/drivers/ driver
> started but in the end I was not able to succeed. With em28xx I could
> go as far as having a /dev/video0 device but with no signal and the
> dmesg log said to ask here for help :) . With the af9015 I had an
> early stop.
> 3) Both the logs are attached.
> 4) I used the driver shipped with the fedora stock kernel because I
> can't compile the ones that I get from
> git://linuxtv.org/media_build.git. I have an error at:
>
> CC [M]  media_build/v4l/as3645a.o
> media_build/v4l/as3645a.c: In function 'as3645a_probe':
> media_build/v4l/as3645a.c:815:2: error: implicit declaration of
> function 'kzalloc' [-Werror=implicit-function-declaration]
> media_build/v4l/as3645a.c:815:8: warning: assignment makes pointer
> from integer without a cast [enabled by default]
> cc1: some warnings being treated as errors
>
> Thank you in advance for any help you might provide on this issue!
>
> ,Best regards
>
> Mario
--
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 FOR 3.3] VIDIOC_LOG_STATUS support for sub-devices

[Mauro Carvalho Chehab]

On 31-12-2011 09:15, Sylwester Nawrocki wrote:
> Hi Mauro,
> 
> The following changes since commit 3220eb73c5647af4c1f18e32c12dccb8adbac59d:
> 
>   s5p-fimc: Add support for alpha component configuration (2011-12-20 19:46:55
> +0100)
> 
> are available in the git repository at:
>   git://git.infradead.org/users/kmpark/linux-samsung v4l_mbus
> 
> This one patch enables VIDIOC_LOG_STATUS on subdev nodes.
> 
> Sylwester Nawrocki (1):
>   v4l: Add VIDIOC_LOG_STATUS support for sub-device nodes


Weird... when trying to pull from your tree, several other patches appeared.
After removing the ones that seemed to be already applied, there are still
those that seemed to still apply:

Nov,17 2011: s5p-fimc: Prevent lock up caused by incomplete H/W initialization
Oct, 1 2011: v4l: Add VIDIOC_LOG_STATUS support for sub-device nodes
Dec, 9 2011: v4l: Add new framesamples field to struct v4l2_mbus_framefmt
Dec,15 2011: v4l: Update subdev drivers to handle framesamples parameter
Dec,12 2011: m5mols: Add buffer size configuration support for compressed 
streams
Nov,21 2011: s5p-fimc: Add media bus framesamples support

Could you please double-check and, if possible, rebase your tree, to avoid
the risk of applying something that is not ok yet, nor to miss something?

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

Re: [RFC/PATCH 1/5] v4l: Convert V4L2_CID_FOCUS_AUTO control to a menu control

[Sylwester Nawrocki]

Hi Sakari,

On 01/04/2012 03:04 PM, Sakari Ailus wrote:
>> On 01/02/2012 12:16 PM, Laurent Pinchart wrote:
 * controls for starting/stopping auto focusing (V4L2_CID_FOCUS_AUTO ==
 false)

V4L2_CID_START_AUTO_FOCUS (button) - start auto focusing,
V4L2_CID_STOP_AUTO_FOCUS  (button) - stop auto focusing (might be also
 useful in V4L2_FOCUS_AUTO == true),
>>>
>>> Maybe V4L2_CID_AUTO_FOCUS_START and V4L2_CID_AUTO_FOCUS_STOP to be 
>>> consistent
>>> with the other proposed controls ?
>>
>> Yes, you're right, I'll change them to make consistent with others.
>> I've noticed that too, but a little bit too late:)
>>
 * auto focus status

V4L2_CID_AUTO_FOCUS_STATUS (menu, read-only) - whether focusing is in
   progress or not,
possible entries:

- V4L2_AUTO_FOCUS_STATUS_IDLE,// auto focusing not enabled or force
 stopped
- V4L2_AUTO_FOCUS_STATUS_BUSY,// focusing in progress
- V4L2_AUTO_FOCUS_STATUS_SUCCESS, // single-shot auto focusing succeed
  // or continuous AF in progress
- V4L2_AUTO_FOCUS_STATUS_FAIL,// auto focusing failed


 * V4L2_CID_FOCUS_AUTO would retain its current semantics:

V4L2_CID_FOCUS_AUTO (boolean) - selects auto/manual focus
false - manual
true  - auto continuous

 * AF algorithm scan range, V4L2_CID_FOCUS_AUTO_SCAN_RANGE with choices:

- V4L2_AUTO_FOCUS_SCAN_RANGE_NORMAL,
- V4L2_AUTO_FOCUS_SCAN_RANGE_MACRO,
- V4L2_AUTO_FOCUS_SCAN_RANGE_INFINITY

>> ...

 * select auto focus mode

 V4L2_CID_AUTO_FOCUS_MODE
  V4L2_AUTO_FOCUS_MODE_NORMAL - "normal" auto focus (whole 
 frame?)
  V4L2_AUTO_FOCUS_MODE_SPOT   - spot location passed with other
  controls or selection API
  V4L2_AUTO_FOCUS_MODE_RECTANGLE  - rectangle passed with other
  controls or selection API
>>>
>>> Soudns good to me.
>>>
> parameter. We also need to discuss how the af statistics window
> configuration is done. I'm not certain there could even be a standardised

 Do we need multiple windows for AF statistics ?

 If not, I'm inclined to use four separate controls for window
 configuration. (X, Y, WIDTH, HEIGHT). This was Hans' preference in
 previous discussions [1].
>>>
>>> For the OMAP3 ISP we need multiple statistics windows. AEWB can use more 
>>> than
>>> 32 windows. Having separate controls for that wouldn't be practical.
>>
>> OK, so the control API in current form doesn't seem capable of setting up the
>> statistics windows. There is also little space in struct v4l2_ext_control for
>> any major extensions.
>>
>> We might need to define dedicated set of selection targets in the selection
>> API for handling multiple windows.
>>
>> Yet, to avoid forcing applications to use the selection API where rectangles
>> aren't needed - only single spot coordinates, how about defining following
>> two controls ?
>>
>> * AF spot coordinates when focus mode is set to V4L2_AUTO_FOCUS_MODE_SPOT
>>
>>   - V4L2_CID_AUTO_FOCUS_POSITION_X - horizontal position in pixels relative
>>  to the left of frame
>>   - V4L2_CID_AUTO_FOCUS_POSITION_Y - vertical position in pixels relative
>>  to the top of frame
> 
> What's a spot focus mode?
> 
> Any AF statistics from a single pixel have no meaning, so there has to be
> more. It sounds like a small rectangle to me. :-)

Yes, it must be a small rectangle. But there may be no way to configure or 
read this rectangle's parameters, hence this menu option. If some hardware 
doesn't implement such feature it can just skip the spot focus menu item.

And in case camera doesn't provide any interface for AF statistics windows 
configuration I don't see a good reason to use the selection API. 

> But being able to provide more windows would be rather important. You don't
> need to look at too special cameras before you can have seven or so focus
> windows.
> 
> The selection API could be used for this, as proposed already. We could have
> a new V4L2_(SUBDEV_)SELECTION_STAT_AF target to configure windows. We could
> add an id field to define the window ID to struct v4l2_(subdev_)selection.
> One control would be required to tell how many statistics windows do you
> have.

Yeah, sounds good to me, better than defining selection target base and
the target pool size. :) Ack.

--
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: [PATCHv4 1/2] v4l: Add new framesamples field to struct v4l2_mbus_framefmt

[Sylwester Nawrocki]

Hi Laurent,

On 12/21/2011 01:20 AM, Laurent Pinchart wrote:
> On Wednesday 14 December 2011 13:23:07 Sylwester Nawrocki wrote:
>> The purpose of the new field is to allow the video pipeline elements
>> to negotiate memory buffer size for compressed data frames, where
>> the buffer size cannot be derived from pixel width and height and
>> the pixel code.
>>
>> For VIDIOC_SUBDEV_S_FMT and VIDIOC_SUBDEV_G_FMT ioctls, the
>> framesamples parameter should be calculated by the driver from pixel
>> width, height, color format and other parameters if required and
>> returned to the caller. This applies to compressed data formats only.
>>
>> The application should propagate the framesamples value, whatever
>> returned at the first sub-device within a data pipeline, i.e. at the
>> pipeline's data source.
>>
>> For compressed data formats the host drivers should internally
>> validate the framesamples parameter values before streaming is
>> enabled, to make sure the memory buffer size requirements are
>> satisfied along the pipeline.
>>
>> Signed-off-by: Sylwester Nawrocki
>> Signed-off-by: Kyungmin Park
>> --
>> There is no changes in this patch comparing to v3.
>> ---
>>   Documentation/DocBook/media/v4l/dev-subdev.xml |   10 --
>>   Documentation/DocBook/media/v4l/subdev-formats.xml |9 -
>>   include/linux/v4l2-mediabus.h  |4 +++-
>>   3 files changed, 19 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/DocBook/media/v4l/dev-subdev.xml
>> b/Documentation/DocBook/media/v4l/dev-subdev.xml index 0916a73..b9d24eb
>> 100644
>> --- a/Documentation/DocBook/media/v4l/dev-subdev.xml
>> +++ b/Documentation/DocBook/media/v4l/dev-subdev.xml
>
>> @@ -160,7 +160,13 @@
>> guaranteed to be supported by the device. In particular, drivers
>> guarantee that a returned format will not be further changed if passed to
>> an&VIDIOC-SUBDEV-S-FMT; call as-is (as long as external parameters, such
>> as
>> -  formats on other pads or links' configuration are not changed).
>> 
>> +  formats on other pads or links' configuration are not changed). When
>> +  a device contains a data encoder, the
>> +framesamples
>> +  field value may be further changed, if parameters of
>> the
>> +  encoding process are changed after the format has been negotiated. In
>> +  such situation applications should use&VIDIOC-SUBDEV-G-FMT; ioctl to
>> +  query an updated format.
>
> Sorry for answering so late. I've been thinking about this topic (as well as
> the proposed new pixelclock field) quite a lot, and one question strikes me
> here (please don't hate me): does userspace need to care about the
> framesamples field ? It looks like the value is only used inside the kernel,
> and we're relying on on userspace to propagate those values between subdevs.

How about a requirements for applications to configure the frame length only 
on sensor (data source) subdev ? The sensor subdev would adjust it, if it 
wouldn't have been consistent with other parameters in struct 
v4l2_mbus_framefmt. And having it "undefined" for non-compressed formats 
rather than requiring it to be set by subdevs to 0 ?

A standard function in the media core could be implemented, if ever needed,
to set framesamples on any remaining subdevs in the pipeline. 

Also the name "framesamples" is a bit odd, just "length" sounds better to me.

> If that's the case, wouldn't it be better to have an in-kernel API to handle
> this ? I'm a bit concerned about forcing userspace to handle internal
> information to userspace if there's no reason to do so.
>
> What's the rationale between your solution, is there a need for the
> framesamples information in userspace ?

Yes, it would be useful. And the control API doesn't seem relevant for it.
Maximum frame length is really a property of data frame on the media bus
which struct v4l2_framefmt describes.
Some sensors allow fine grained configuration of their embedded JPEG 
encoders and having frame length configurable directly on subdevs would
be useful.

--
Regards,
Sylwester

>> Drivers automatically propagate formats inside sub-devices.
>> When a try or active format is set on a pad, corresponding formats on
>> other pads diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml
>> b/Documentation/DocBook/media/v4l/subdev-formats.xml index
>> 49c532e..7c202a1 100644
>> --- a/Documentation/DocBook/media/v4l/subdev-formats.xml
>> +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml
>> @@ -33,9 +33,16 @@
>>  Image colorspace, from&v4l2-colorspace;. See
>>for details.
>>  
>> +
>> +__u32
>> +framesamples
>> +Maximum number of bus samples per frame for compressed data
>> +formats. For uncompressed formats drivers and applications must
>> +set this parameter to zero.
>> +
>>  
>>  __u32
>> -reserved[7]
>> +reserved[6]
>>  Reserved for future extensions. Applications and drivers must

Re: [RFC/PATCH 1/5] v4l: Convert V4L2_CID_FOCUS_AUTO control to a menu control

[Sylwester Nawrocki]

Hi Sakari,

On 01/04/2012 02:22 PM, Sakari Ailus wrote:
>> The V4L2_CID_FOCUS_AUTO menu control has currently following items:
>>   0 - V4L2_FOCUS_MANUAL,
>>   1 - V4L2_FOCUS_AUTO,
>>   2 - V4L2_FOCUS_AUTO_MACRO,
>>   3 - V4L2_FOCUS_AUTO_CONTINUOUS.
>
> I would put the macro mode to a separate menu since it's configuration for
> how the regular AF works rather than really different mode.

 Yes, makes sense. Most likely there could be also continuous macro auto 
 focus..
 I don't have yet an idea what could be a name for that new menu though.
>>>
>>> V4L2_CID_FOCUS_AUTO_DISTANCE? It could then have choices FULL or MACRO.
>>
>> How about V4L2_CID_FOCUS_AUTO_SCAN_RANGE ? Which would then have choices:
>>  NORMAL,
>>  MACRO,
>>  INFINITY
>> ?
> 
> What does INFINITY signify? That lens is permanently positioned there?

Yes, I think that's just what it is supposed to mean, but I would have to double
check in the specs.

HeungJun, would you have some more details about the INFINITY setting ?

> The name of the control sounds good to me, but I might change the order of
> FOCUS and AUTO in it.

Ok, I'll fix it.

--

Thanks,
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] vpif_capture.c: v4l2_device_register() is called too late in vpif_probe()

[Mauro Carvalho Chehab]

On 13-12-2011 10:19, Hadli, Manjunath wrote:
> Hans,
> 
> On Tue, Dec 13, 2011 at 15:14:42, Hans Verkuil wrote:
>> The function v4l2_device_register() is called too late in vpif_probe().
>> This meant that vpif_obj.v4l2_dev is accessed before it is initialized which 
>> caused a crash.
>>
>> This used to work in the past, but video_register_device() is now actually 
>> using the v4l2_dev pointer.
> I also found this issue today. Good catch!
>>
>> Note that vpif_display.c doesn't have this bug, there v4l2_device_register() 
>> is called at the beginning of vpif_probe.
>>
>> Signed-off-by: Georgios Plakaris 
>> Signed-off-by: Hans Verkuil 
>>
>> diff --git a/drivers/media/video/davinci/vpif_capture.c 
>> b/drivers/media/video/davinci/vpif_capture.c
>> index 49e4deb..6504e40 100644
>> --- a/drivers/media/video/davinci/vpif_capture.c
>> +++ b/drivers/media/video/davinci/vpif_capture.c
>> @@ -2177,6 +2177,12 @@ static __init int vpif_probe(struct platform_device 
>> *pdev)
>>  return err;
>>  }
>>  
>> +err = v4l2_device_register(vpif_dev, &vpif_obj.v4l2_dev);
>> +if (err) {
>> +v4l2_err(vpif_dev->driver, "Error registering v4l2 device\n");
>> +return err;
>> +}
>> +
>>  k = 0;
>>  while ((res = platform_get_resource(pdev, IORESOURCE_IRQ, k))) {
>>  for (i = res->start; i <= res->end; i++) { @@ -2246,12 +2252,6 
>> @@ static __init int vpif_probe(struct platform_device *pdev)
>>  goto probe_out;
>>  }
>>  
>> -err = v4l2_device_register(vpif_dev, &vpif_obj.v4l2_dev);
>> -if (err) {
>> -v4l2_err(vpif_dev->driver, "Error registering v4l2 device\n");
>> -goto probe_subdev_out;
>> -}
>> -
>>  for (i = 0; i < subdev_count; i++) {
>>  subdevdata = &config->subdev_info[i];
>>  vpif_obj.sd[i] =
>> @@ -2281,7 +2281,6 @@ probe_subdev_out:
>>  
>>  j = VPIF_CAPTURE_MAX_DEVICES;
>>  probe_out:
>> -v4l2_device_unregister(&vpif_obj.v4l2_dev);
>>  for (k = 0; k < j; k++) {
>>  /* Get the pointer to the channel object */
>>  ch = vpif_obj.dev[k];
>> @@ -2303,6 +2302,7 @@ vpif_int_err:
>>  if (res)
>>  i = res->end;
>>  }
>> +v4l2_device_unregister(&vpif_obj.v4l2_dev);
>>  return err;
>>  }
>>  
>>
>>
>>
> 
> ACKed by me. 

Please, reply with the standard way:
Acked-by: Manjunath Hadli 

Otherwise, patchwork will not catch your ack.

> 
> Thx,
> -Manju
> 
> --
> 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: [RFC/PATCH] [media] dw2102: use symbolic names for dw2102_table indices

[Mauro Carvalho Chehab]

On 23-12-2011 21:00, Jonathan Nieder wrote:
> dw2102_properties et al refer to entries in the USB-id table using
> hard-coded indices, as in "&dw2102_table[6]", which means adding new
> entries before the end of the list has the potential to introduce bugs
> in code elsewhere in the file.
> 
> Use C99-style initializers with symbolic names for each index to avoid
> this.  This way, other device tables wanting to reuse the USB ids can
> use expressions like "&dw2102_table[TEVII_S630]" that do not change as
> the entries in the table are reordered.
> 
> Signed-off-by: Jonathan Nieder 
> ---
> Patrick Boettcher wrote:
> 
>> Due to the use of the reference in the USB-id table adding the new set at 
>> the end of the list is actually the best way. Adding them in the middle will 
>> cause a lot of changes and bugs.
> 
> Good catch.  That seems like an accident waiting to happen.  How about
> something like this (untested)?
> 
>  drivers/media/dvb/dvb-usb/dw2102.c |   78 
> ++--
>  1 files changed, 48 insertions(+), 30 deletions(-)
> 
> diff --git a/drivers/media/dvb/dvb-usb/dw2102.c 
> b/drivers/media/dvb/dvb-usb/dw2102.c
> index 64add7cb1fd3..9a1863dc7232 100644
> --- a/drivers/media/dvb/dvb-usb/dw2102.c
> +++ b/drivers/media/dvb/dvb-usb/dw2102.c
> @@ -1435,22 +1435,40 @@ static int dw2102_rc_query(struct dvb_usb_device *d, 
> u32 *event, int *state)
>   return 0;
>  }
>  
> +enum dw2102_table_entry {
> + CYPRESS_DW2102,
> + CYPRESS_DW2101,
> + CYPRESS_DW2104,
> + TEVII_S650,
> + TERRATEC_CINERGY_S,
> + CYPRESS_DW3101,
> + TEVII_S630,
> + PROF_1100,
> + TEVII_S660,
> + PROF_7500,
> + GENIATECH_SU3000,
> + TERRATEC_CINERGY_S2,
> + TEVII_S480_1,
> + TEVII_S480_2,
> + X3M_SPC1400HD,
> +};
> +
>  static struct usb_device_id dw2102_table[] = {
> - {USB_DEVICE(USB_VID_CYPRESS, USB_PID_DW2102)},
> - {USB_DEVICE(USB_VID_CYPRESS, 0x2101)},
> - {USB_DEVICE(USB_VID_CYPRESS, USB_PID_DW2104)},
> - {USB_DEVICE(0x9022, USB_PID_TEVII_S650)},
> - {USB_DEVICE(USB_VID_TERRATEC, USB_PID_CINERGY_S)},
> - {USB_DEVICE(USB_VID_CYPRESS, USB_PID_DW3101)},
> - {USB_DEVICE(0x9022, USB_PID_TEVII_S630)},
> - {USB_DEVICE(0x3011, USB_PID_PROF_1100)},
> - {USB_DEVICE(0x9022, USB_PID_TEVII_S660)},
> - {USB_DEVICE(0x3034, 0x7500)},
> - {USB_DEVICE(0x1f4d, 0x3000)},
> - {USB_DEVICE(USB_VID_TERRATEC, 0x00a8)},
> - {USB_DEVICE(0x9022, USB_PID_TEVII_S480_1)},
> - {USB_DEVICE(0x9022, USB_PID_TEVII_S480_2)},
> - {USB_DEVICE(0x1f4d, 0x3100)},
> + [CYPRESS_DW2102] = {USB_DEVICE(USB_VID_CYPRESS, USB_PID_DW2102)},
> + [CYPRESS_DW2101] = {USB_DEVICE(USB_VID_CYPRESS, 0x2101)},
> + [CYPRESS_DW2104] = {USB_DEVICE(USB_VID_CYPRESS, USB_PID_DW2104)},
> + [TEVII_S650] = {USB_DEVICE(0x9022, USB_PID_TEVII_S650)},
> + [TERRATEC_CINERGY_S] = {USB_DEVICE(USB_VID_TERRATEC, 
> USB_PID_CINERGY_S)},
> + [CYPRESS_DW3101] = {USB_DEVICE(USB_VID_CYPRESS, USB_PID_DW3101)},
> + [TEVII_S630] = {USB_DEVICE(0x9022, USB_PID_TEVII_S630)},
> + [PROF_1100] = {USB_DEVICE(0x3011, USB_PID_PROF_1100)},
> + [TEVII_S660] = {USB_DEVICE(0x9022, USB_PID_TEVII_S660)},
> + [PROF_7500] = {USB_DEVICE(0x3034, 0x7500)},
> + [GENIATECH_SU3000] = {USB_DEVICE(0x1f4d, 0x3000)},
> + [TERRATEC_CINERGY_S2] = {USB_DEVICE(USB_VID_TERRATEC, 0x00a8)},
> + [TEVII_S480_1] = {USB_DEVICE(0x9022, USB_PID_TEVII_S480_1)},
> + [TEVII_S480_2] = {USB_DEVICE(0x9022, USB_PID_TEVII_S480_2)},
> + [X3M_SPC1400HD] = {USB_DEVICE(0x1f4d, 0x3100)},
>   { }
>  };
>  
> @@ -1610,15 +1628,15 @@ static struct dvb_usb_device_properties 
> dw2102_properties = {
>   .num_device_descs = 3,
>   .devices = {
>   {"DVBWorld DVB-S 2102 USB2.0",
> - {&dw2102_table[0], NULL},
> + {&dw2102_table[CYPRESS_DW2102], NULL},
>   {NULL},
>   },
>   {"DVBWorld DVB-S 2101 USB2.0",
> - {&dw2102_table[1], NULL},
> + {&dw2102_table[CYPRESS_DW2101], NULL},
>   {NULL},
>   },
>   {"TerraTec Cinergy S USB",
> - {&dw2102_table[4], NULL},
> + {&dw2102_table[TERRATEC_CINERGY_S], NULL},
>   {NULL},
>   },
>   }
> @@ -1664,11 +1682,11 @@ static struct dvb_usb_device_properties 
> dw2104_properties = {
>   .num_device_descs = 2,
>   .devices = {
>   { "DVBWorld DW2104 USB2.0",
> - {&dw2102_table[2], NULL},
> + {&dw2102_table[CYPRESS_DW2104], NULL},
>   {NULL},
>   },
>   { "TeVii S650 USB2.0",
> - {&dw2102_table[3], NULL},
> + {&dw2102_table[TEVII_S650], NULL},
>   {NULL},
>   },
>   }
> @@ -1715,7 +1733,7 @@ sta

Re: Add support for new Terratec DVB USB IDs

[Mauro Carvalho Chehab]

On 22-12-2011 21:44, Jonathan Nieder wrote:
> Hi,
> 
> Eduard Bloch wrote[1]:
> 
>> current revision of the Cinergy S2 USB box from Terratec seems to use
>> another USB-IDs. The manufacturer provides patches at
>> http://linux.terratec.de/tv_en.html and it seems like the only
>> difference is really just the new ID and a couple of init flag changes.
>>
>> Their patch is not exactly for the linux-3.x tree but for the current
>> s2-liplianin drivers, OTOH they still look similar enough and porting
>> the patch was straight-forward. I also added the patch for Terratec S7
>> which is not tested yet but shouldn't do any harm.
> [...]
> 
> Eduard, meet the LinuxTV project.  linux-media folks, meet Eduard.
> Patch follows.
> 
> Eduard: may we have your sign-off?  Please see
> Documentation/SubmittingPatches, section 12 "Sign your work" for what
> this means.

Eduard/Jonathan,

Please provide your Signed-off-by: your name 

thanks!
Mauro

> 
> My only other hint is that it would be better to add the new device
> IDs in some logical place in the list near the older ones, instead of
> at the end where it is more likely to collide with other patches in
> flight.  So if rerolling the patches, it might be useful to do that.
> 
> -- >8 --
> From: Eduard Bloch 
> Date: Thu, 22 Dec 2011 19:46:54 +0100
> Subject: new device IDs used by some Terratec USB devices
> 
> The changes are extracted from ID patches in tarballs at
> http://linux.terratec.de/tv_en.html (for S7 and Cinergy S2 USB HD), and
> slightly modified to match the state of s2-liplianin tree used in linux-3.x so
> far.
> ---
> Thanks for your work,
> Jonathan
> 
> [1] http://bugs.debian.org/653026
> 
> diff -urd linux-2.6-3.1.5.debian/drivers/media/dvb/dvb-usb/az6027.c 
> linux-2.6-3.1.5/drivers/media/dvb/dvb-usb/az6027.c
> --- linux-2.6-3.1.5.debian/drivers/media/dvb/dvb-usb/az6027.c 2011-12-09 
> 17:57:05.0 +0100
> +++ linux-2.6-3.1.5/drivers/media/dvb/dvb-usb/az6027.c2011-12-22 
> 19:42:25.655675023 +0100
> @@ -1090,6 +1090,7 @@
>   { USB_DEVICE(USB_VID_TECHNISAT, USB_PID_TECHNISAT_USB2_HDCI_V1) },
>   { USB_DEVICE(USB_VID_TECHNISAT, USB_PID_TECHNISAT_USB2_HDCI_V2) },
>   { USB_DEVICE(USB_VID_ELGATO, USB_PID_ELGATO_EYETV_SAT) },
> + { USB_DEVICE(USB_VID_TERRATEC,  USB_PID_TERRATEC_DVBS2CI_V3) },
>   { },
>  };
>  
> @@ -1135,7 +1136,7 @@
>  
>   .i2c_algo = &az6027_i2c_algo,
>  
> - .num_device_descs = 6,
> + .num_device_descs = 7,
>   .devices = {
>   {
>   .name = "AZUREWAVE DVB-S/S2 USB2.0 (AZ6027)",
> @@ -1161,6 +1162,10 @@
>   .name = "Elgato EyeTV Sat",
>   .cold_ids = { &az6027_usb_table[5], NULL },
>   .warm_ids = { NULL },
> + }, {
> + .name = "TERRATEC S7 Rev.3",
> + .cold_ids = { &az6027_usb_table[6], NULL },
> + .warm_ids = { NULL },
>   },
>   { NULL },
>   }
> diff -urd linux-2.6-3.1.5.debian/drivers/media/dvb/dvb-usb/dvb-usb-ids.h 
> linux-2.6-3.1.5/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
> --- linux-2.6-3.1.5.debian/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
> 2011-12-09 17:57:05.0 +0100
> +++ linux-2.6-3.1.5/drivers/media/dvb/dvb-usb/dvb-usb-ids.h   2011-12-22 
> 19:40:02.208934727 +0100
> @@ -319,6 +319,7 @@
>  #define USB_PID_AZUREWAVE_AZ6027 0x3275
>  #define USB_PID_TERRATEC_DVBS2CI_V1  0x10a4
>  #define USB_PID_TERRATEC_DVBS2CI_V2  0x10ac
> +#define USB_PID_TERRATEC_DVBS2CI_V3  0x10b0
>  #define USB_PID_TECHNISAT_USB2_HDCI_V1   0x0001
>  #define USB_PID_TECHNISAT_USB2_HDCI_V2   0x0002
>  #define USB_PID_TECHNISAT_AIRSTAR_TELESTICK_20x0004
> diff -urd linux-2.6-3.1.5.debian/drivers/media/dvb/dvb-usb/dw2102.c 
> linux-2.6-3.1.5/drivers/media/dvb/dvb-usb/dw2102.c
> --- linux-2.6-3.1.5.debian/drivers/media/dvb/dvb-usb/dw2102.c 2011-12-09 
> 17:57:05.0 +0100
> +++ linux-2.6-3.1.5/drivers/media/dvb/dvb-usb/dw2102.c2011-12-22 
> 19:43:16.588387654 +0100
> @@ -1181,6 +1181,14 @@
>  {
>   u8 obuf[3] = { 0xe, 0x80, 0 };
>   u8 ibuf[] = { 0 };
> + 
> + if (dvb_usb_generic_rw(d->dev, obuf, 3, ibuf, 1, 0) < 0)
> + err("command 0x0e transfer failed.");
> +
> + //power on su3000
> + obuf[0] = 0xe;
> + obuf[1] = 0x02;
> + obuf[2] = 1;
>  
>   if (dvb_usb_generic_rw(d->dev, obuf, 3, ibuf, 1, 0) < 0)
>   err("command 0x0e transfer failed.");
> @@ -1451,6 +1459,7 @@
>   {USB_DEVICE(0x9022, USB_PID_TEVII_S480_1)},
>   {USB_DEVICE(0x9022, USB_PID_TEVII_S480_2)},
>   {USB_DEVICE(0x1f4d, 0x3100)},
> + {USB_DEVICE(USB_VID_TERRATEC, 0x00b0)},
>   { }
>  };
>  
> @@ -1824,7 +1833,7 @@
>   }
>   }
>   },
> - .num_device_descs = 3,
> + .num_device_d

Re: Using OMAP3 ISP live display and snapshot sample applications

[Laurent Pinchart]

Hi James,

On Friday 06 January 2012 07:24:54 James wrote:

[snip]

> After googling for the warning, I proceed with the following steps to
> make the application on Steve's GNOME-R13 image from this site as it
> has all the tools for native-compilation on the Tobi board.
> 
> 1) Inside /usr/src/linux, run "make headers_install ARCH=arm" and my
> /usr/include is now populated with lots of files.

omap3-isp-live requires recent kernel headers that are not shipped by 
distributions yet, so you need to install them to some location first. "make 
headers_install ARCH=arm" should install them to /usr/src/linux/usr/include, 
not /usr/include.

> 2) Inside omap3-isp-live, I ran "make KDIR=/usr/src/linux
> CROSS_COMPILE=arm-angstrom-linux-gnueabi-".
> 
> This gave me an error about not finding linux/omap3isp.h file.
> Thus, I modified the 2 Makefile and replaced "-I$(KDIR)/usr/include"
> with "-I$(KDIR)/include"

That's weird. The make headers_install step above should have installed the 
headers in /usr/src/linux/usr/include, so the makefile should be correct.

> Ran "make KDIR=/usr/src/linux
> CROSS_COMPILE=arm-angstrom-linux-gnueabi-" again and it compiled
> nicely without warnings about using kernel headers from user space.
> 
> Only 3 warnings about
> 
> a) omap3isp.c:271:13: warning: 'omap3_isp_pool_free_buffers' defined
> but not used

Fixed in the latest version.

> b) omap3isp.c:329:15: warning: 'nbufs' may be used uninitialized in
> this function

Fixed in the latest version as well.

> c) subdev.c:49:20: warning: 'pixelcode_to_string' defined but not used

I'll fix that, but it's harmless.

> Hope I got it right compiling it this time!! (^^)"
> 
> 3) Copied isp/libomap3isp.so to /usr/lib/ directory when this message
> appeared when I ran ./live -h
> 
> "./live: error while loading shared libraries: libomap3isp.so: cannot
> open shared object file: No such file or directory"
> 
> 4) Ran ./live again and got this error message "unable to find video
> output device"

That should be fixed in the latest version. Could you please upgrade ?

> overo: setting xclk to 2500 hz
> Device /dev/videovero: setting xclk to 0 hz
> o6 opened: OMAP3 ISP resizer output (media).
> viewfinder configured for 2011 1024x768
> error: unable to find video output device
> 
> The output of the DVI goes 'blue' and nothing shown.
> What is missing?
> 
> lsmod shows the list of modules loaded.
> 
> Module  Size  Used by
> fuse   59943  3
> bufferclass_ti  4976  0
> omaplfb 8025  0
> pvrsrvkm  146868  2 bufferclass_ti,omaplfb
> mt9v032 5958  1
> omap3_isp 104303  0
> v4l2_common 8543  2 mt9v032,omap3_isp
> videodev   78271  3 mt9v032,omap3_isp,v4l2_common
> libertas_sdio  14871  0
> media  11885  3 mt9v032,omap3_isp,videodev
> libertas   92472  1 libertas_sdio
> cfg80211  157222  1 libertas
> lib802115291  1 libertas
> firmware_class  6269  2 libertas_sdio,libertas
> ads784610331  0
> ipv6  226224  18
> 
> 5) Ran ./snapshot and it continues till Ctrl+C.
> Does it has any output others then those messages?
> 
> Many thanks in adv.

-- 
Regards,

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

Re: Using OMAP3 ISP live display and snapshot sample applications

[Laurent Pinchart]

Hi James,

On Wednesday 04 January 2012 08:07:23 James wrote:
> On Tue, Jan 3, 2012 at 7:17 PM, Laurent Pinchart wrote:
> > On Tuesday 03 January 2012 10:40:10 James wrote:
> >> Hi Laurent,
> >> 
> >> Happy New Year!!
> > 
> > Thank you. Happy New Year to you as well. May 2012 bring you a workable
> > OMAP3 ISP solution ;-)
> 
> Yeah! that's on #1 of my 2012 wishlist!! (^^)
> 
> But, it start off with a disappointment on the quest to get
> "gst-launch v4l2src" to work..
> http://patches.openembedded.org/patch/8895/
> 
> Saw reported success in get v4l2src to work with MT9V032 by applying
> the hack but no luck with my Y12 monochrome sensor. (-.-)"
> 
> >> I saw that there is a simple viewfinder in your repo for OMAP3 and
> >> wish to know more about it.
> >> 
> >> http://git.ideasonboard.org/?p=omap3-isp-live.git;a=summary
> >> 
> >> I intend to test it with my 12-bit (Y12) monochrome camera sensor
> >> driver, running on top of Gumstix's (Steve v3.0) kernel.
> >> 
> >> Is it workable at the moment?
> > 
> > The application is usable but supports raw Bayer sensors only at the
> > moment. It requires a frame buffer and an omap_vout device (both should
> > be located automatically) and configures the OMAP3 ISP pipeline
> > automatically to produce the display resolution.
> 
> Will there be a need to patch for Y12 support or workable out-of-the-box?

It will work out of the box when someone implements support for Y12 :-)

> Likely your previous notes, I know that 12-bit Y12 to the screen is an
> overkill but will it be able to capture Y12 from CCDC output and then
> output to the screen?
> 
> Y12 sensor-> CCDC -> CCDC output -> screen

The omap_vout driver supports V4L2_PIX_FMT_RGB565, V4L2_PIX_FMT_RGB32, 
V4L2_PIX_FMT_RGB24, V4L2_PIX_FMT_YUYV and V4L2_PIX_FMT_UYVY only. To display 
Y12 data you will need to convert them to 10 bits in the CCDC (that's already 
implemented) and then to YUYV in the preview engine (that's not implemented 
yet).

> I've one board connected to a LCD monitor via a DVI chip using GS's
> Tobi board as reference and another via 4.3" LG LCD Touchscreen using
> GS's Chestnut board as reference.
> 
> Many thanks in adv

-- 
Regards,

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

Re: [RFC 04/17] v4l: VIDIOC_SUBDEV_S_SELECTION and VIDIOC_SUBDEV_G_SELECTION IOCTLs

[Laurent Pinchart]

Hi Sakari,

On Friday 06 January 2012 12:27:03 Sakari Ailus wrote:
> Laurent Pinchart wrote:
> > On Tuesday 20 December 2011 21:27:56 Sakari Ailus wrote:
> >> From: Sakari Ailus 
> >> 
> >> Add support for VIDIOC_SUBDEV_S_SELECTION and VIDIOC_SUBDEV_G_SELECTION
> >> IOCTLs. They replace functionality provided by VIDIOC_SUBDEV_S_CROP and
> >> VIDIOC_SUBDEV_G_CROP IOCTLs and also add new functionality (composing).
> >> 
> >> VIDIOC_SUBDEV_G_CROP and VIDIOC_SUBDEV_S_CROP continue to be supported.
> > 
> > As those ioctls are experimental, should we deprecate them ?
> 
> I'm also in favour of doing that. But I'll make it a separate patch.
> 
> >> Signed-off-by: Sakari Ailus 
> >> ---
> >> 
> >>  drivers/media/video/v4l2-subdev.c |   26 -
> >>  include/linux/v4l2-subdev.h   |   45
> >>  ++ include/media/v4l2-subdev.h   |
> >> 5 
> >>  3 files changed, 75 insertions(+), 1 deletions(-)
> >> 
> >> diff --git a/drivers/media/video/v4l2-subdev.c
> >> b/drivers/media/video/v4l2-subdev.c index 65ade5f..e8ae098 100644
> >> --- a/drivers/media/video/v4l2-subdev.c
> >> +++ b/drivers/media/video/v4l2-subdev.c
> >> @@ -36,13 +36,17 @@ static int subdev_fh_init(struct v4l2_subdev_fh *fh,
> >> struct v4l2_subdev *sd) {
> >> 
> >>  #if defined(CONFIG_VIDEO_V4L2_SUBDEV_API)
> >>  
> >>/* Allocate try format and crop in the same memory block */
> >> 
> >> -  fh->try_fmt = kzalloc((sizeof(*fh->try_fmt) + sizeof(*fh->try_crop))
> >> +  fh->try_fmt = kzalloc((sizeof(*fh->try_fmt) + sizeof(*fh->try_crop)
> >> + + sizeof(*fh->try_compose))
> >> 
> >>  * sd->entity.num_pads, GFP_KERNEL);
> > 
> > Could you check how the 3 structures are aligned on 64-bit platforms ?
> > I'm a bit worried about the compiler expecting a 64-bit alignment for
> > one of them, and getting only a 32-bit alignment in the end.
> > 
> > What about using kcalloc ?
> 
> kcalloc won't make a difference --- see the implementation. Do you think
> this is really an issue in practice?

It won't make a difference for the alignment, it's just that we allocate an 
array, so kcalloc seemed right.

> If we want to ensure alignment I'd just allocate them separately. Or
> create a struct out of them locally, and get the pointers from that
> struct --- then the alignment would be the same as if those were part of
> a single struct. That achieves the desired result and also keeps error
> handling trivial.
>
> I wouldn't want to start relying on the alignment based on the sizes of
> these structures.

Sounds good to me. Allocating them as part of a bigger structure internally 
could be more efficient than separate allocations, but I'm fine with both.

-- 
Regards,

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

Re: [RFC 06/17] v4l: Add selections documentation.

[Laurent Pinchart]

Hi Sakari,

Thanks for the patch.

On Tuesday 20 December 2011 21:27:58 Sakari Ailus wrote:

[snip]

> diff --git a/Documentation/DocBook/media/v4l/dev-subdev.xml
> b/Documentation/DocBook/media/v4l/dev-subdev.xml index 0916a73..722db60
> 100644
> --- a/Documentation/DocBook/media/v4l/dev-subdev.xml
> +++ b/Documentation/DocBook/media/v4l/dev-subdev.xml

[snip]

> @@ -288,26 +288,81 @@

[snip]

> +  Scaling operation changes the size of the image by scaling
> +  it to new dimensions. Some sub-devices support it. The scaled
> +  size (width and height) is represented by &v4l2-rect;. In the
> +  case of scaling, top and left will always be zero. Scaling is
> +  configured using &sub-subdev-g-selection; and
> +  V4L2_SUBDEV_SEL_COMPOSE_ACTIVE selection
> +  target on the sink pad of the subdev. The scaling is performed
> +  related to the width and height of the crop rectangle on the
> +  subdev's sink pad.
> +
> +  As for pad formats, drivers store try and active
> +  rectangles for the selection targets of ACTIVE type  +  linkend="v4l2-subdev-selection-targets">.
> +
> +  On sink pads, cropping is applied relatively to the
> +  current pad format. The pad format represents the image size as
> +  received by the sub-device from the previous block in the
> +  pipeline, and the crop rectangle represents the sub-image that
> +  will be transmitted further inside the sub-device for
> +  processing.
> +
> +  On source pads, cropping is similar to sink pads, with the
> +  exception that the source size from which the cropping is
> +  performed, is the COMPOSE rectangle on the sink pad. In both
> +  sink and source pads, the crop rectangle must be entirely
> +  containted inside the source image size for the crop
> +  operation.
> +
> +  The drivers should always use the closest possible
> +  rectangle the user requests on all selection targets, unless
> +  specificly told otherwise +  linkend="v4l2-subdev-selection-flags">.
> +

This sounds a bit confusing to me. One issue is that composing is not formally 
defined. I think it would help if you could draw a diagram that shows how the 
operations are applied, and modify the text to describe the diagram, using the 
natural order of the compose and crop operations on sink and source pads.

> +
> +  Order of configuration and format propagation
> +
> +  The order of image processing steps will always be from
> +  the sink pad towards the source pad. This is also reflected in
> +  the order in which the configuration must be performed by the
> +  user. The format is propagated within the subdev along the later
> +  processing steps. For example, setting the sink pad format
> +  causes all the selection rectangles and the source pad format to
> +  be set to sink pad format --- if allowed by the hardware, and if
> +  not, then closest possible. The coordinates to a step always
> +  refer to the active size of the previous step.

This also sounds a bit ambiguous if I try to ignore the fact that I know how 
it works :-) You should at least make it explicit that propagation inside 
subdevs is performed by the driver(s), and that propagation outside subdevs is 
to be handled by userspace.

> +  
> + Sink pad format. The user configures the sink pad
> + format. This format defines the parameters of the image the
> + entity receives through the pad for further processing.
> 
> -  Cropping behaviour on output pads is not defined.
> + Sink pad active crop selection. The sink pad crop
> + defines the performed to the sink pad format.
> 
> + Sink pad active compose selection. The sink pad compose
> + rectangle defines the scaling ratio compared to the size of
> + the sink pad crop rectangle.
> +
> + Source pad active crop selection. Crop on the source
> + pad defines crop performed to the image scaled according to
> + the sink pad compose rectangle.
> +
> + Source pad active compose selection. The source pad
> + compose defines the size and location of the compose
> + rectangle.
> +
> + Source pad format. The source pad format defines the
> + output pixel format of the subdev, as well as the other
> + parameters with the exception of the image width and
> + height.
> +
> +  
>  
> +
>
> 
>&sub-subdev-formats;

[snip]

> diff --git a/Documentation/DocBook/media/v4l/vidioc-subdev-g-selection.xml
> b/Documentation/DocBook/media/v4l/vidioc-subdev-g-selection.xml new file
> mode 100644
> index 000..5fbcd65
> --- /dev/null
> +++ b/Documentation/DocBook/media/v4l/vidioc-subdev-g-selection.xml
> @@ -0,0 +1,226 @@

[snip]

> +  
> +Description
> +
> +
> +  Experimental
> +  This is an experimental
> +  interface and may change in the future.
> +
> +
> +The selections are used to configure various image
> + 

Re: [RFC 04/17] v4l: VIDIOC_SUBDEV_S_SELECTION and VIDIOC_SUBDEV_G_SELECTION IOCTLs

[Sakari Ailus]

Hi Laurent,

Thanks for the comments!

Laurent Pinchart wrote:
> On Tuesday 20 December 2011 21:27:56 Sakari Ailus wrote:
>> From: Sakari Ailus 
>>
>> Add support for VIDIOC_SUBDEV_S_SELECTION and VIDIOC_SUBDEV_G_SELECTION
>> IOCTLs. They replace functionality provided by VIDIOC_SUBDEV_S_CROP and
>> VIDIOC_SUBDEV_G_CROP IOCTLs and also add new functionality (composing).
>>
>> VIDIOC_SUBDEV_G_CROP and VIDIOC_SUBDEV_S_CROP continue to be supported.
> 
> As those ioctls are experimental, should we deprecate them ?

I'm also in favour of doing that. But I'll make it a separate patch.

>> Signed-off-by: Sakari Ailus 
>> ---
>>  drivers/media/video/v4l2-subdev.c |   26 -
>>  include/linux/v4l2-subdev.h   |   45 ++
>>  include/media/v4l2-subdev.h   |5 
>>  3 files changed, 75 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/media/video/v4l2-subdev.c
>> b/drivers/media/video/v4l2-subdev.c index 65ade5f..e8ae098 100644
>> --- a/drivers/media/video/v4l2-subdev.c
>> +++ b/drivers/media/video/v4l2-subdev.c
>> @@ -36,13 +36,17 @@ static int subdev_fh_init(struct v4l2_subdev_fh *fh,
>> struct v4l2_subdev *sd) {
>>  #if defined(CONFIG_VIDEO_V4L2_SUBDEV_API)
>>  /* Allocate try format and crop in the same memory block */
>> -fh->try_fmt = kzalloc((sizeof(*fh->try_fmt) + sizeof(*fh->try_crop))
>> +fh->try_fmt = kzalloc((sizeof(*fh->try_fmt) + sizeof(*fh->try_crop)
>> +   + sizeof(*fh->try_compose))
>>* sd->entity.num_pads, GFP_KERNEL);
> 
> Could you check how the 3 structures are aligned on 64-bit platforms ? I'm a 
> bit worried about the compiler expecting a 64-bit alignment for one of them, 
> and getting only a 32-bit alignment in the end.
> 
> What about using kcalloc ?

kcalloc won't make a difference --- see the implementation. Do you think
this is really an issue in practice?

If we want to ensure alignment I'd just allocate them separately. Or
create a struct out of them locally, and get the pointers from that
struct --- then the alignment would be the same as if those were part of
a single struct. That achieves the desired result and also keeps error
handling trivial.

I wouldn't want to start relying on the alignment based on the sizes of
these structures.

>>  if (fh->try_fmt == NULL)
>>  return -ENOMEM;
>>
>>  fh->try_crop = (struct v4l2_rect *)
>>  (fh->try_fmt + sd->entity.num_pads);
>> +
>> +fh->try_compose = (struct v4l2_rect *)
>> +(fh->try_crop + sd->entity.num_pads);
>>  #endif
>>  return 0;
>>  }
>> @@ -281,6 +285,26 @@ static long subdev_do_ioctl(struct file *file,
>> unsigned int cmd, void *arg) return v4l2_subdev_call(sd, pad,
>> enum_frame_interval, subdev_fh, fie);
>>  }
>> +
>> +case VIDIOC_SUBDEV_G_SELECTION: {
>> +struct v4l2_subdev_selection *sel = arg;
> 
> Shouldn't you check sel->which ?

Yes.

>> +if (sel->pad >= sd->entity.num_pads)
>> +return -EINVAL;
>> +
>> +return v4l2_subdev_call(
>> +sd, pad, get_selection, subdev_fh, sel);
>> +}
>> +
>> +case VIDIOC_SUBDEV_S_SELECTION: {
>> +struct v4l2_subdev_selection *sel = arg;
> 
> And here too ?

Yes.

>> +if (sel->pad >= sd->entity.num_pads)
>> +return -EINVAL;
>> +
>> +return v4l2_subdev_call(
>> +sd, pad, set_selection, subdev_fh, sel);
>> +}
>>  #endif
>>  default:
>>  return v4l2_subdev_call(sd, core, ioctl, cmd, arg);
>> diff --git a/include/linux/v4l2-subdev.h b/include/linux/v4l2-subdev.h
>> index ed29cbb..d53d775 100644
>> --- a/include/linux/v4l2-subdev.h
>> +++ b/include/linux/v4l2-subdev.h
>> @@ -123,6 +123,47 @@ struct v4l2_subdev_frame_interval_enum {
>>  __u32 reserved[9];
>>  };
>>
>> +#define V4L2_SUBDEV_SEL_FLAG_SIZE_GE(1 << 0)
>> +#define V4L2_SUBDEV_SEL_FLAG_SIZE_LE(1 << 1)
>> +#define V4L2_SUBDEV_SEL_FLAG_KEEP_CONFIG(1 << 2)
>> +
>> +/* active cropping area */
>> +#define V4L2_SUBDEV_SEL_TGT_CROP_ACTIVE 0
>> +/* default cropping area */
>> +#define V4L2_SUBDEV_SEL_TGT_CROP_DEFAULT1
>> +/* cropping bounds */
>> +#define V4L2_SUBDEV_SEL_TGT_CROP_BOUNDS 2
>> +/* current composing area */
>> +#define V4L2_SUBDEV_SEL_TGT_COMPOSE_ACTIVE  256
>> +/* default composing area */
>> +#define V4L2_SUBDEV_SEL_TGT_COMPOSE_DEFAULT 257
>> +/* composing bounds */
>> +#define V4L2_SUBDEV_SEL_TGT_COMPOSE_BOUNDS  258
>> +
>> +
>> +/**
>> + * struct v4l2_subdev_selection - selection info
>> + *
>> + * @which: either V4L2_SUBDEV_FORMAT_ACTIVE or V4L2_SUBDEV_FORMAT_TRY
>> + * @pad: pad number, as reported by the media API
>> + * @target: selection target, used to choose one of possible rectangles
>> + * @flags: constraints flags
>> + 

Re: Pause/Resume and flush for V4L2 codec drivers.

[Hans Verkuil]

On Friday, January 06, 2012 03:31:37 vka...@codeaurora.org wrote:
> Hi
> 
> I am trying to implement v4l2 driver for video decoders. The problem I am
> facing is how to send pause/resume and flush commands from user-space to
> v4l2 driver. I am thinking of using controls for this. Has anyone done
> this before or if anyone has any ideas please let me know. Appreciate your
> help.

See this patch series:

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

Does this give you what you need?

Regards,

Hans

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

[GIT PATCHES FOR 3.3] gspca: fixes and new driver, pwc: large cleanup

[Hans de Goede]

Hi Mauro (et all),

Please pull from my tree for various gspca fixes, a new gspca sub driver and
some major pwc driver cleanups, removing a lot of old driver specific API,
per feature-removal-schedule.txt.

The following changes since commit 6cb393c82255c448a92754f2a2a6b715bd9418dc:

  [media] drxk_hard: fix locking issues when changing the delsys (2012-01-05 
16:44:10 -0200)

are available in the git repository at:
  git://linuxtv.org/hgoede/gspca.git media-for_v3.3

Hans de Goede (17):
  gspca: Fix falling back to lower isoc alt settings
  gspca_sonixb: Fix exposure control min/max value for coarse expo sensors
  gspca_pac7302: Add usb-id for 145f:013c
  gscpa_ov519: Fix the bandwidth calc for enabling compression
  gscpa_t613: Add support for the camera button
  pwc: Use v4l2-device and v4l2-fh
  pwc: Properly mark device_hint as unused in all probe error paths
  pwc: Make auto white balance speed and delay available as v4l2 controls
  pwc: Rework locking
  pwc: Read new preset values when changing awb control to a preset
  pwc: Remove driver specific sysfs interface
  pwc: Remove driver specific use of pixfmt.priv in the pwc driver
  pwc: Remove dead snapshot code
  pwc: Remove driver specific ioctls
  pwc: Remove software emulation of arbritary resolutions
  pwc: Get rid of compression module parameter
  pwc: Properly fill all fields on try_fmt

Theodore Kilgore (1):
  gspca: Add jl2005bcd sub driver

 Documentation/DocBook/media/v4l/pixfmt.xml |5 +
 Documentation/feature-removal-schedule.txt |   35 --
 Documentation/video4linux/gspca.txt|1 +
 drivers/media/video/gspca/Kconfig  |   10 +
 drivers/media/video/gspca/Makefile |2 +
 drivers/media/video/gspca/gspca.c  |2 +-
 drivers/media/video/gspca/jl2005bcd.c  |  554 +
 drivers/media/video/gspca/ov519.c  |4 +-
 drivers/media/video/gspca/pac7302.c|1 +
 drivers/media/video/gspca/sonixb.c |   15 +-
 drivers/media/video/gspca/t613.c   |   25 +
 drivers/media/video/pwc/pwc-ctrl.c |  723 ++--
 drivers/media/video/pwc/pwc-dec23.c|  288 ++--
 drivers/media/video/pwc/pwc-dec23.h|5 +-
 drivers/media/video/pwc/pwc-if.c   |  297 
 drivers/media/video/pwc/pwc-kiara.h|2 +-
 drivers/media/video/pwc/pwc-misc.c |   87 +---
 drivers/media/video/pwc/pwc-timon.h|2 +-
 drivers/media/video/pwc/pwc-uncompress.c   |   46 +--
 drivers/media/video/pwc/pwc-v4l.c  |  258 +-
 drivers/media/video/pwc/pwc.h  |   66 ++--
 include/linux/videodev2.h  |1 +
 include/media/pwc-ioctl.h  |  323 -
 23 files changed, 997 insertions(+), 1755 deletions(-)
 create mode 100644 drivers/media/video/gspca/jl2005bcd.c
 delete mode 100644 include/media/pwc-ioctl.h

Thanks & Regards,

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

Re: [RFC 03/17] vivi: Add an integer menu test control

[Laurent Pinchart]

Hi Sakari,

On Friday 06 January 2012 11:22:00 Sakari Ailus wrote:
> Sakari Ailus wrote:
> ...
> 
> > I put it there to limit the maximum to 8 instead of 9, but 9 would be
> > equally good. I'll change it.
> 
> Or not. 8 is still the index of the last value. min is one  to start the
> menu from the second item. Would you like that to be changed to zero?

If it was done on purpose I'm fine with it. I was just pointing it out in case 
it was done by mistake.

-- 
Regards,

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

Re: [RFC 07/17] v4l: Add pixelrate to struct v4l2_mbus_framefmt

[Laurent Pinchart]

Hi Sakari,

Thanks for the patch.

On Tuesday 20 December 2011 21:27:59 Sakari Ailus wrote:
> From: Sakari Ailus 
> 
> Pixelrate is an essential part of the image data parameters. Add this.
> Together, the current parameters also define the frame rate.
> 
> Sensors do not have a concept of frame rate; pixelrate is much more
> meaningful in this context. Also, it is best to combine the pixelrate with
> the other format parameters since there are dependencies between them.
>
> Signed-off-by: Sakari Ailus 
> ---
>  Documentation/DocBook/media/v4l/subdev-formats.xml |   10 +-
>  include/linux/v4l2-mediabus.h  |4 +++-
>  2 files changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml
> b/Documentation/DocBook/media/v4l/subdev-formats.xml index
> 49c532e..a6a6630 100644
> --- a/Documentation/DocBook/media/v4l/subdev-formats.xml
> +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml
> @@ -35,7 +35,15 @@
>   
>   
> __u32
> -   reserved[7]
> +   pixelrate
> +   Pixel rate in kp/s.

kPix/s or kPixel/s ?

> This clock is the maximum rate at

Is it really a clock ?

> +   which pixels are transferred on the bus. The
> +   pixelrate field is
> +   read-only.

Does that mean that userspace isn't required to propagate the value down the 
pipeline when configuring it ? I'm fine with that, but it should probably be 
documented explictly somewhere to make sure that drivers don't rely on it.

> + 
> + 
> +   __u32
> +   reserved[6]
> Reserved for future extensions. Applications and drivers must
> set the array to zero.
>   
> diff --git a/include/linux/v4l2-mediabus.h b/include/linux/v4l2-mediabus.h
> index 5ea7f75..35c6b96 100644
> --- a/include/linux/v4l2-mediabus.h
> +++ b/include/linux/v4l2-mediabus.h
> @@ -101,6 +101,7 @@ enum v4l2_mbus_pixelcode {
>   * @code:data format code (from enum v4l2_mbus_pixelcode)
>   * @field:   used interlacing type (from enum v4l2_field)
>   * @colorspace:  colorspace of the data (from enum v4l2_colorspace)
> + * @pixel_clock: pixel clock, in kHz

I think you forgot to update the comment.

>   */
>  struct v4l2_mbus_framefmt {
>   __u32   width;
> @@ -108,7 +109,8 @@ struct v4l2_mbus_framefmt {
>   __u32   code;
>   __u32   field;
>   __u32   colorspace;
> - __u32   reserved[7];
> + __u32   pixelrate;
> + __u32   reserved[6];
>  };
> 
>  #endif

-- 
Regards,

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

Re: [RFC 03/17] vivi: Add an integer menu test control

[Sakari Ailus]

Sakari Ailus wrote:
...
> I put it there to limit the maximum to 8 instead of 9, but 9 would be
> equally good. I'll change it.

Or not. 8 is still the index of the last value. min is one  to start the
menu from the second item. Would you like that to be changed to zero?

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

Re: [RFC 17/17] rm680: Add camera init

[Laurent Pinchart]

Hi Sakari,

Thanks for the patch.

On Tuesday 20 December 2011 21:28:09 Sakari Ailus wrote:
> This currently introduces an extra file to the arch/arm/mach-omap2
> directory: board-rm680-camera.c. Keeping the device tree in mind, the
> context of the file could be represented as static data with one exception:
> the external clock to the sensor.
> 
> This external clock is provided by the OMAP 3 SoC and required by the
> sensor. The issue is that the clock originates from the ISP and not from
> PRCM block as the other clocks and thus is not supported by the clock
> framework. Otherwise the sensor driver could just clk_get() and
> clk_enable() it, just like the regulators and gpios.

This will hopefully be fixable with the new generic clock struct. Have you had 
a look at it lately BTW ?

> Signed-off-by: Sakari Ailus 
> ---
>  arch/arm/mach-omap2/Makefile |3 +-
>  arch/arm/mach-omap2/board-rm680-camera.c |  408
> ++ arch/arm/mach-omap2/board-rm680.c| 
>  42 +++
>  3 files changed, 452 insertions(+), 1 deletions(-)
>  create mode 100644 arch/arm/mach-omap2/board-rm680-camera.c
> 
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index 69ab1c0..1444bc5 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -201,7 +201,8 @@ obj-$(CONFIG_MACH_OMAP3_PANDORA)  +=
> board-omap3pandora.o obj-$(CONFIG_MACH_OMAP_3430SDP)  += 
> board-3430sdp.o
>  obj-$(CONFIG_MACH_NOKIA_N8X0)+= board-n8x0.o
>  obj-$(CONFIG_MACH_NOKIA_RM680)   += board-rm680.o \
> -sdram-nokia.o
> +sdram-nokia.o \
> +board-rm680-camera.o
>  obj-$(CONFIG_MACH_NOKIA_RX51)+= board-rx51.o \
>  sdram-nokia.o \
>  board-rx51-peripherals.o \
> diff --git a/arch/arm/mach-omap2/board-rm680-camera.c
> b/arch/arm/mach-omap2/board-rm680-camera.c new file mode 100644
> index 000..4cc1ced
> --- /dev/null
> +++ b/arch/arm/mach-omap2/board-rm680-camera.c
> @@ -0,0 +1,408 @@
> +/**
> + * arch/arm/mach-omap2/board-rm680-camera.c
> + *
> + * Copyright (C) 2010--2011 Nokia Corporation

2012 ? :-)

> + * Contact: Sakari Ailus 
> + *
> + * Based on board-rx71-camera.c by Vimarsh Zutshi

This one isn't upstream, I'm not sure if it's worth mentioning it.

> + * Based on board-rx51-camera.c by Sakari Ailus
> + *
> + * 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., 51 Franklin St, Fifth Floor, Boston, MA
> + * 02110-1301 USA
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#include "../../../drivers/media/video/omap3isp/isp.h"

What do we still miss in  ?

> +#include 
> +#include 
> +#include 
> +
> +#include "../../../drivers/media/video/smiapp.h"

Time to create  ?

> +
> +#include "devices.h"
> +
> +#define SEC_CAMERA_RESET_GPIO97
> +
> +#define RM680_PRI_SENSOR 1
> +#define RM680_PRI_LENS   2
> +#define RM680_SEC_SENSOR 3
> +#define MAIN_CAMERA_XCLK ISP_XCLK_A
> +#define SEC_CAMERA_XCLK  ISP_XCLK_B
> +
> +/*
> + *
> + * HW initialization
> + *
> + *
> + */
> +static int __init rm680_sec_camera_init(void)
> +{
> + if (gpio_request(SEC_CAMERA_RESET_GPIO, "sec_camera reset") != 0) {
> + printk(KERN_INFO "%s: unable to acquire secondary "
> +"camera reset gpio\n", __func__);
> + return -ENODEV;
> + }
> +
> + /* XSHUTDOWN off, reset  */
> + gpio_direction_output(SEC_CAMERA_RESET_GPIO, 0);
> + gpio_set_value(SEC_CAMERA_RESET_GPIO, 0);

gpio_request_one() would be helpful here (and possibly in other locations in 
this file).

> +
> + return 0;
> +}
> +
> +static int __init rm680_camera_hw_init(void)
> +{
> + return rm680_sec_camera_init();

Maybe you could merge the two functions ?

> +}
> +
> +/*
> + *
> + * Main Camera Module EXTCLK
> + * Used by the sensor and the actuator driver.
> + *
> + */
> +static struct camera_xclk {
> + u32 hz;
> + u32 lock;
> + u8 xclksel;
> +} cameras_xclk;
> +
> +static DEFINE_MUTEX(lock_xclk);
> +
> +static int rm680_update_xclk(struct v4l2_subdev *subdev, u32 hz, u32
> which, +   u8 xclksel)
> +{
> + struct isp_dev

Re: [RFC 03/17] vivi: Add an integer menu test control

[Sakari Ailus]

Hi Laurent,

Laurent Pinchart wrote:
> Hi Sakari,
> 
> Thanks for the patch.

Thanks for the review!

> On Tuesday 20 December 2011 21:27:55 Sakari Ailus wrote:
>> From: Sakari Ailus 
>>
>> Add an integer menu test control for the vivi driver.
>>
>> Signed-off-by: Sakari Ailus 
>> ---
>>  drivers/media/video/vivi.c |   21 +
>>  1 files changed, 21 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/media/video/vivi.c b/drivers/media/video/vivi.c
>> index 7d754fb..763ec23 100644
>> --- a/drivers/media/video/vivi.c
>> +++ b/drivers/media/video/vivi.c
>> @@ -177,6 +177,7 @@ struct vivi_dev {
>>  struct v4l2_ctrl   *menu;
>>  struct v4l2_ctrl   *string;
>>  struct v4l2_ctrl   *bitmask;
>> +struct v4l2_ctrl   *int_menu;
>>
>>  spinlock_t slock;
>>  struct mutex   mutex;
>> @@ -503,6 +504,10 @@ static void vivi_fillbuff(struct vivi_dev *dev, struct
>> vivi_buffer *buf) dev->boolean->cur.val,
>>  dev->menu->qmenu[dev->menu->cur.val],
>>  dev->string->cur.string);
>> +snprintf(str, sizeof(str), " integer_menu %s, value %lld ",
>> +dev->int_menu->qmenu[dev->int_menu->cur.val],
> 
> Shouldn't you print the content of qmenu_int as a 64-bit integer instead ?

Oh, yes; I should. Also the value would be wrong, as well as the menu
item array --- should be the int one.

>> +dev->int64->cur.val64);
> 
> Shouldn't this be dev->int_menu->cur.val ?
> 
>> +gen_text(dev, vbuf, line++ * 16, 16, str);
>>  mutex_unlock(&dev->ctrl_handler.lock);
>>  gen_text(dev, vbuf, line++ * 16, 16, str);
>>  if (dev->button_pressed) {
>> @@ -1183,6 +1188,22 @@ static const struct v4l2_ctrl_config
>> vivi_ctrl_bitmask = { .step = 0,
>>  };
>>
>> +static const s64 * const vivi_ctrl_int_menu_values[] = {
>> +1, 1, 2, 3, 5, 8, 13, 21, 42,
>> +};
>> +
>> +static const struct v4l2_ctrl_config vivi_ctrl_string = {
>> +.ops = &vivi_ctrl_ops,
>> +.id = VIDI_CID_CUSTOM_BASE + 7
>> +.name = "Integer menu",
>> +.type = V4L2_CTRL_TYPE_INTEGER_MENU,
>> +.min = 1,
>> +.max = 8,
> 
> There are 9 values in your vivi_ctrl_int_menu_values array. Is 8 on purpose 
> here ?

I put it there to limit the maximum to 8 instead of 9, but 9 would be
equally good. I'll change it.

>> +.def = 4,
>> +.menu_skip_mask = 0x02,
>> +.qmenu_int = &vivi_ctrl_int_menu_values,
>> +};
>> +
>>  static const struct v4l2_file_operations vivi_fops = {
>>  .owner  = THIS_MODULE,
>>  .open   = v4l2_fh_open,
> 


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

Re: [RFC 14/17] omap3isp: Use pixelrate from sensor media bus frameformat

[Laurent Pinchart]

Hi Sakari,

Thanks for the patch.

On Tuesday 20 December 2011 21:28:06 Sakari Ailus wrote:
> From: Sakari Ailus 
> 
> Configure the ISP based on the pixelrate in media bus frame format.
> Previously the same was configured from the board code.
> 
> Signed-off-by: Sakari Ailus 
> ---
>  drivers/media/video/omap3isp/isp.c |   24 +---
>  drivers/media/video/omap3isp/isp.h |1 -
>  2 files changed, 21 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/video/omap3isp/isp.c
> b/drivers/media/video/omap3isp/isp.c index 6020fd7..92f9716 100644
> --- a/drivers/media/video/omap3isp/isp.c
> +++ b/drivers/media/video/omap3isp/isp.c
> @@ -749,10 +749,14 @@ static int isp_pipeline_enable(struct isp_pipeline
> *pipe,
> 
>   entity = &pipe->output->video.entity;
>   while (1) {
> - pad = &entity->pads[0];
> - if (!(pad->flags & MEDIA_PAD_FL_SINK))
> + /*
> +  * Is this an external subdev connected to us? If so,
> +  * we're done.
> +  */
> + if (subdev && subdev->host_priv)
>   break;

This doesn't seem to be related to the patch title. Should it be moved to a 
separate patch ? You could also move the check to the bottom of the while 
loop, it would allow you to remove the first part of the condition as subdev 
will always be non-NULL then (or even possible as the while() condition).

> + pad = &entity->pads[0];
>   pad = media_entity_remote_source(pad);
>   if (pad == NULL ||
>   media_entity_type(pad->entity) != MEDIA_ENT_T_V4L2_SUBDEV)
> @@ -762,6 +766,21 @@ static int isp_pipeline_enable(struct isp_pipeline
> *pipe, prev_subdev = subdev;
>   subdev = media_entity_to_v4l2_subdev(entity);
> 
> + /* Configure CCDC pixel clock */
> + if (subdev->host_priv) {
> + struct v4l2_subdev_format fmt;
> +
> + fmt.pad = pad->index;
> + fmt.which = V4L2_SUBDEV_FORMAT_ACTIVE;
> + ret = v4l2_subdev_call(subdev, pad, get_fmt,
> +NULL, &fmt);
> + if (ret < 0)
> + return -EINVAL;
> +
> + isp_set_pixel_clock(isp,
> + fmt.format.pixelrate * 1000);
> + }
> +
>   /* Configure CSI-2 receiver based on sensor format. */
>   if (prev_subdev == &isp->isp_csi2a.subdev
> 
>   || prev_subdev == &isp->isp_csi2c.subdev) {
> 
> @@ -2102,7 +2121,6 @@ static int isp_probe(struct platform_device *pdev)
> 
>   isp->autoidle = autoidle;
>   isp->platform_cb.set_xclk = isp_set_xclk;
> - isp->platform_cb.set_pixel_clock = isp_set_pixel_clock;
> 
>   mutex_init(&isp->isp_mutex);
>   spin_lock_init(&isp->stat_lock);
> diff --git a/drivers/media/video/omap3isp/isp.h
> b/drivers/media/video/omap3isp/isp.h index c5935ae..7d73a39 100644
> --- a/drivers/media/video/omap3isp/isp.h
> +++ b/drivers/media/video/omap3isp/isp.h
> @@ -126,7 +126,6 @@ struct isp_reg {
> 
>  struct isp_platform_callback {
>   u32 (*set_xclk)(struct isp_device *isp, u32 xclk, u8 xclksel);
> - void (*set_pixel_clock)(struct isp_device *isp, unsigned int pixelclk);
>  };
> 
>  /*

-- 
Regards,

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

Re: [RFC 02/17] v4l: Document integer menu controls

[Sakari Ailus]

Hi Laurent,

Laurent Pinchart wrote:
> Hi Sakari,
> 
> Thanks for the patch.
> 
> On Tuesday 20 December 2011 21:27:54 Sakari Ailus wrote:
>> From: Sakari Ailus 
>>
>> Signed-off-by: Sakari Ailus 
>> ---
>>  Documentation/DocBook/media/v4l/compat.xml |   10 +
>>  Documentation/DocBook/media/v4l/v4l2.xml   |7 
>>  .../DocBook/media/v4l/vidioc-queryctrl.xml |   39
>> +++- 3 files changed, 54 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/DocBook/media/v4l/compat.xml
>> b/Documentation/DocBook/media/v4l/compat.xml index b68698f..569efd1 100644
>> --- a/Documentation/DocBook/media/v4l/compat.xml
>> +++ b/Documentation/DocBook/media/v4l/compat.xml
>> @@ -2379,6 +2379,16 @@ that used it. It was originally scheduled for
>> removal in 2.6.35. 
>>  
>>
>> +
>> +  V4L2 in Linux 3.3
> 
> Seems it will be for 3.4 :-) Same for Documentation/DocBook/media/v4l/v4l2.xml

Right. I'll make the change for now but I don't of course mind if we get
this to 3.3 already. However, if we want a driver using this go in at
the same time, the smia++ driver for almost certain is not going to be
3.3 since it depends on a large set of other patches.

Regards,

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

Re: [RFC 12/17] omap3isp: Add lane configuration to platform data

[Laurent Pinchart]

Hi Sakari,

Thanks for the patch.

On Tuesday 20 December 2011 21:28:04 Sakari Ailus wrote:
> From: Sakari Ailus 
> 
> Add lane configuration (order of clock and data lane) to platform data on
> both CCP2 and CSI-2.
> 
> Signed-off-by: Sakari Ailus 
> ---
>  drivers/media/video/omap3isp/ispcsiphy.h |   15 ++-
>  include/media/omap3isp.h |   15 +++
>  2 files changed, 17 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/media/video/omap3isp/ispcsiphy.h
> b/drivers/media/video/omap3isp/ispcsiphy.h index 9596dc6..e93a661 100644
> --- a/drivers/media/video/omap3isp/ispcsiphy.h
> +++ b/drivers/media/video/omap3isp/ispcsiphy.h
> @@ -27,22 +27,11 @@
>  #ifndef OMAP3_ISP_CSI_PHY_H
>  #define OMAP3_ISP_CSI_PHY_H
> 
> +#include 
> +
>  struct isp_csi2_device;
>  struct regulator;
> 
> -struct csiphy_lane {
> - u8 pos;
> - u8 pol;
> -};
> -
> -#define ISP_CSIPHY2_NUM_DATA_LANES   2
> -#define ISP_CSIPHY1_NUM_DATA_LANES   1
> -
> -struct isp_csiphy_lanes_cfg {
> - struct csiphy_lane data[ISP_CSIPHY2_NUM_DATA_LANES];
> - struct csiphy_lane clk;
> -};
> -
>  struct isp_csiphy_dphy_cfg {
>   u8 ths_term;
>   u8 ths_settle;
> diff --git a/include/media/omap3isp.h b/include/media/omap3isp.h
> index e917b1d..8fe0bdf 100644
> --- a/include/media/omap3isp.h
> +++ b/include/media/omap3isp.h
> @@ -86,6 +86,19 @@ enum {
>   ISP_CCP2_MODE_CCP2 = 1,
>  };
> 
> +struct csiphy_lane {
> + u8 pos;
> + u8 pol;
> +};
> +
> +#define ISP_CSIPHY2_NUM_DATA_LANES   2
> +#define ISP_CSIPHY1_NUM_DATA_LANES   1
> +
> +struct isp_csiphy_lanes_cfg {
> + struct csiphy_lane data[ISP_CSIPHY2_NUM_DATA_LANES];
> + struct csiphy_lane clk;
> +};

Could you please document the two structures using kerneldoc ?

> +
>  /**
>   * struct isp_ccp2_platform_data - CCP2 interface platform data
>   * @strobe_clk_pol: Strobe/clock polarity
> @@ -105,6 +118,7 @@ struct isp_ccp2_platform_data {
>   unsigned int ccp2_mode:1;
>   unsigned int phy_layer:1;
>   unsigned int vpclk_div:2;
> + struct isp_csiphy_lanes_cfg *lanecfg;

Lane configuration is mandatory, what about embedding struct 
isp_csiphy_lanes_cfg inside struct isp_ccp2_platform instead of having a 
pointer ?

>  };
> 
>  /**
> @@ -115,6 +129,7 @@ struct isp_ccp2_platform_data {
>  struct isp_csi2_platform_data {
>   unsigned crc:1;
>   unsigned vpclk_div:2;
> + struct isp_csiphy_lanes_cfg *lanecfg;

Same here.

>  };
> 
>  struct isp_subdev_i2c_board_info {

-- 
Regards,

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

Re: [RFC 13/17] omap3isp: Configure CSI-2 phy based on platform data

[Laurent Pinchart]

Hi Sakari,

Thanks for the patch.

On Tuesday 20 December 2011 21:28:05 Sakari Ailus wrote:
> From: Sakari Ailus 
> 
> Configure CSI-2 phy based on platform data in the ISP driver rather than in
> platform code.
> 
> Signed-off-by: Sakari Ailus 
> ---
>  drivers/media/video/omap3isp/isp.c   |   38 --
>  drivers/media/video/omap3isp/isp.h   |3 -
>  drivers/media/video/omap3isp/ispcsiphy.c |   83 +++
>  drivers/media/video/omap3isp/ispcsiphy.h |4 ++
>  4 files changed, 111 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/media/video/omap3isp/isp.c
> b/drivers/media/video/omap3isp/isp.c index b818cac..6020fd7 100644
> --- a/drivers/media/video/omap3isp/isp.c
> +++ b/drivers/media/video/omap3isp/isp.c
> @@ -737,7 +737,7 @@ static int isp_pipeline_enable(struct isp_pipeline
> *pipe, struct isp_device *isp = pipe->output->isp;
>   struct media_entity *entity;
>   struct media_pad *pad;
> - struct v4l2_subdev *subdev;
> + struct v4l2_subdev *subdev = NULL, *prev_subdev;
>   unsigned long flags;
>   int ret;
> 
> @@ -759,11 +759,41 @@ static int isp_pipeline_enable(struct isp_pipeline
> *pipe, break;
> 
>   entity = pad->entity;
> + prev_subdev = subdev;
>   subdev = media_entity_to_v4l2_subdev(entity);
> 
> - ret = v4l2_subdev_call(subdev, video, s_stream, mode);
> - if (ret < 0 && ret != -ENOIOCTLCMD)
> - return ret;
> + /* Configure CSI-2 receiver based on sensor format. */
> + if (prev_subdev == &isp->isp_csi2a.subdev
> + || prev_subdev == &isp->isp_csi2c.subdev) {
> + struct v4l2_subdev_format fmt;
> +
> + fmt.pad = pad->index;
> + fmt.which = V4L2_SUBDEV_FORMAT_ACTIVE;
> + ret = v4l2_subdev_call(subdev, pad, get_fmt,
> +NULL, &fmt);
> + if (ret < 0)
> + return -EPIPE;
> +
> + ret = omap3isp_csiphy_config(
> + isp, prev_subdev, subdev,
> + &fmt.format);
> + if (ret < 0)
> + return -EPIPE;
> +
> + /* Start CSI-2 after configuration. */
> + ret = v4l2_subdev_call(prev_subdev, video,
> +s_stream, mode);
> + if (ret < 0 && ret != -ENOIOCTLCMD)
> + return ret;
> + }
> +
> + /* Start any other subdev except the CSI-2 receivers. */
> + if (subdev != &isp->isp_csi2a.subdev
> + && subdev != &isp->isp_csi2c.subdev) {
> + ret = v4l2_subdev_call(subdev, video, s_stream, mode);
> + if (ret < 0 && ret != -ENOIOCTLCMD)
> + return ret;
> + }

What about moving this to the CSI2 s_stream subdev operation ?

> 
>   if (subdev == &isp->isp_ccdc.subdev) {
>   v4l2_subdev_call(&isp->isp_aewb.subdev, video,
> diff --git a/drivers/media/video/omap3isp/isp.h
> b/drivers/media/video/omap3isp/isp.h index 705946e..c5935ae 100644
> --- a/drivers/media/video/omap3isp/isp.h
> +++ b/drivers/media/video/omap3isp/isp.h
> @@ -126,9 +126,6 @@ struct isp_reg {
> 
>  struct isp_platform_callback {
>   u32 (*set_xclk)(struct isp_device *isp, u32 xclk, u8 xclksel);
> - int (*csiphy_config)(struct isp_csiphy *phy,
> -  struct isp_csiphy_dphy_cfg *dphy,
> -  struct isp_csiphy_lanes_cfg *lanes);
>   void (*set_pixel_clock)(struct isp_device *isp, unsigned int pixelclk);
>  };
> 
> diff --git a/drivers/media/video/omap3isp/ispcsiphy.c
> b/drivers/media/video/omap3isp/ispcsiphy.c index 5be37ce..f027ece 100644
> --- a/drivers/media/video/omap3isp/ispcsiphy.c
> +++ b/drivers/media/video/omap3isp/ispcsiphy.c
> @@ -28,6 +28,8 @@
>  #include 
>  #include 
> 
> +#include "../../../../arch/arm/mach-omap2/control.h"
> +

#include 

(untested) ?

>  #include "isp.h"
>  #include "ispreg.h"
>  #include "ispcsiphy.h"
> @@ -138,15 +140,78 @@ static void csiphy_dphy_config(struct isp_csiphy
> *phy) isp_reg_writel(phy->isp, reg, phy->phy_regs, ISPCSIPHY_REG1);
>  }
> 
> -static int csiphy_config(struct isp_csiphy *phy,
> -  struct isp_csiphy_dphy_cfg *dphy,
> -  struct isp_csiphy_lanes_cfg *lanes)
> +/*
> + * TCLK values are OK at their reset values
> + */
> +#define TCLK_TERM0
> +#define TCLK_MISS1
> +#define TCLK_SETTLE  14
> +
> +int omap3isp_csiphy_config(struct isp_device *isp,
> +struct v4l2_subdev *csi2_subdev,
> +struct v4l2_subdev *sensor,
> +struct v4l2_mbus_framefmt *sensor_fmt)
>  {
> + struct i

Re: [RFC 01/17] v4l: Introduce integer menu controls

[Sakari Ailus]

Hi Laurent,

Laurent Pinchart wrote:
> Hi Sakari,
> 
> Thanks for the patch.

Thanks for the review!

> On Tuesday 20 December 2011 21:27:53 Sakari Ailus wrote:
>> From: Sakari Ailus 
>>
>> Create a new control type called V4L2_CTRL_TYPE_INTEGER_MENU. Integer menu
>> controls are just like menu controls but the menu items are 64-bit integers
>> rather than strings.
> 
> [snip]
> 
>> diff --git a/drivers/media/video/v4l2-ctrls.c
>> b/drivers/media/video/v4l2-ctrls.c index 0f415da..083bb79 100644
>> --- a/drivers/media/video/v4l2-ctrls.c
>> +++ b/drivers/media/video/v4l2-ctrls.c
> 
>> @@ -1775,16 +1797,22 @@ int v4l2_querymenu(struct v4l2_ctrl_handler *hdl,
>> struct v4l2_querymenu *qm)
>>
>>  qm->reserved = 0;
>>  /* Sanity checks */
> 
> You should return -EINVAL here if the control is not of a menu type. It was 
> done implictly before by the ctrl->qmenu == NULL check, but that's now 
> conditioned to the control type being V4L2_CTRL_TYPE_MENU.

Good point. Fixed.

>> -if (ctrl->qmenu == NULL ||
>> +if ((ctrl->type == V4L2_CTRL_TYPE_MENU && ctrl->qmenu == NULL) ||
>> +(ctrl->type == V4L2_CTRL_TYPE_INTEGER_MENU
>> + && ctrl->qmenu_int == NULL) ||
>>  i < ctrl->minimum || i > ctrl->maximum)
>>  return -EINVAL;
>>  /* Use mask to see if this menu item should be skipped */
>>  if (ctrl->menu_skip_mask & (1 << i))
>>  return -EINVAL;
>>  /* Empty menu items should also be skipped */
>> -if (ctrl->qmenu[i] == NULL || ctrl->qmenu[i][0] == '\0')
>> -return -EINVAL;
>> -strlcpy(qm->name, ctrl->qmenu[i], sizeof(qm->name));
>> +if (ctrl->type == V4L2_CTRL_TYPE_MENU) {
>> +if (ctrl->qmenu[i] == NULL || ctrl->qmenu[i][0] == '\0')
>> +return -EINVAL;
>> +strlcpy(qm->name, ctrl->qmenu[i], sizeof(qm->name));
>> +} else if (ctrl->type == V4L2_CTRL_TYPE_INTEGER_MENU) {
> 
> And you can then replace the else if by an else.

As well as this one.

>> +qm->value = ctrl->qmenu_int[i];
>> +}
>>  return 0;
>>  }
>>  EXPORT_SYMBOL(v4l2_querymenu);
> 


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

Re: [RFC 09/17] v4l: Add pad op for pipeline validation

[Laurent Pinchart]

Hi Sakari,

Thanks for the patch.

On Tuesday 20 December 2011 21:28:01 Sakari Ailus wrote:
> From: Sakari Ailus 
> 
> smiapp_pad_ops.validate_pipeline is intended to validate the full pipeline
> which is implemented by the driver to which the subdev implementing this op
> belongs to.

Should this be documented in Documentation/video4linux/v4l2-framework.txt ?

> The validate_pipeline op must also call validate_pipeline on any external
> entity which is linked to its sink pads.

I'm uncertain about this. Subdev drivers would then have to implement the 
pipeline walk logic, resulting in duplicate code. Our current situation isn't 
optimal either: walking the pipeline should be implemented in the media code. 
Would it suit your needs if the validate_pipeline operation was replaced by a 
validate_link operation, with a media_pipeline_validate() function in the 
media core to walk the pipeline and call validate_link in each pad (or maybe 
each sink pad) ?

> Signed-off-by: Sakari Ailus 
> ---
>  include/media/v4l2-subdev.h |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
> index 26eeaa4..a5ebe86 100644
> --- a/include/media/v4l2-subdev.h
> +++ b/include/media/v4l2-subdev.h
> @@ -470,6 +470,7 @@ struct v4l2_subdev_pad_ops {
>struct v4l2_subdev_selection *sel);
>   int (*set_selection)(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh,
>struct v4l2_subdev_selection *sel);
> + int (*validate_pipeline)(struct v4l2_subdev *sd);
>  };
> 
>  struct v4l2_subdev_ops {

-- 
Regards,

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