Re: [PULL] soc-camera 2.6.32: new driver and a compile-fix

[Paul Mundt]

On Fri, Sep 25, 2009 at 01:29:08AM -0300, Mauro Carvalho Chehab wrote:
> Em Fri, 25 Sep 2009 11:52:19 +0900
> Paul Mundt  escreveu:
> 
> > On Wed, Sep 23, 2009 at 06:02:04PM +0200, Guennadi Liakhovetski wrote:
> > > On Wed, 23 Sep 2009, Guennadi Liakhovetski wrote:
> > > 
> > > > Hi Mauro
> > > > 
> > > > The following two patches are for 2.6.32. One of them fixes 
> > > > sh_mobile_ceu_camera compile breakage, and another one adds a new 
> > > > soc-camera / v4l2-subdev driver for ov9640. Marek, looks like you 
> > > > didn't 
> > > > even compile tested your driver with CONFIG_VIDEO_ADV_DEBUG=y. It 
> > > > didn't 
> > > > compile, so, I had to fix it.
> > > > 
> > > > Please pull from http://linuxtv.org/hg/~gliakhovetski/v4l-dvb
> > > > 
> > > > for the following 2 changesets:
> > > > 
> > > > 01/02: V4L2: Add a v4l2-subdev (soc-camera) driver for OmniVision 
> > > > OV9640 sensor
> > > > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=1dec51b360a3
> > > > 
> > > > 02/02: sh_mobile_ceu_camera: fix compile breakage, caused by a bad merge
> > > > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=a798c751f06d
> > > 
> > > Sorry, forgot to mention, somehow, the git and the hg versions got 
> > > different merges, both wrong, so, for the git the following equivalent 
> > > patch will be needed, after which the two versions shall be in sync again:
> > > 
> > > sh_mobile_ceu_camera: fix compile breakage, caused by a bad merge
> > > 
> > > Signed-off-by: Guennadi Liakhovetski 
> > 
> > So who wants to push this one? I'm planning on sending Linus updates
> > shortly, so can roll this in with mine, as it seems to have missed the
> > last v4l merge.
> 
> Paul,
> 
> It seems fine to me if you could do it. I have some pending stuff on other
> kernel areas, so I'd appreciate if you can handle this fix.
> 
> You have my ack on it:
> 
> Acked-by: Mauro Carvalho Chehab 
> 
Ok, I'll queue it up, thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PULL] soc-camera 2.6.32: new driver and a compile-fix

[Mauro Carvalho Chehab]

Em Fri, 25 Sep 2009 11:52:19 +0900
Paul Mundt  escreveu:

> On Wed, Sep 23, 2009 at 06:02:04PM +0200, Guennadi Liakhovetski wrote:
> > On Wed, 23 Sep 2009, Guennadi Liakhovetski wrote:
> > 
> > > Hi Mauro
> > > 
> > > The following two patches are for 2.6.32. One of them fixes 
> > > sh_mobile_ceu_camera compile breakage, and another one adds a new 
> > > soc-camera / v4l2-subdev driver for ov9640. Marek, looks like you didn't 
> > > even compile tested your driver with CONFIG_VIDEO_ADV_DEBUG=y. It didn't 
> > > compile, so, I had to fix it.
> > > 
> > > Please pull from http://linuxtv.org/hg/~gliakhovetski/v4l-dvb
> > > 
> > > for the following 2 changesets:
> > > 
> > > 01/02: V4L2: Add a v4l2-subdev (soc-camera) driver for OmniVision OV9640 
> > > sensor
> > > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=1dec51b360a3
> > > 
> > > 02/02: sh_mobile_ceu_camera: fix compile breakage, caused by a bad merge
> > > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=a798c751f06d
> > 
> > Sorry, forgot to mention, somehow, the git and the hg versions got 
> > different merges, both wrong, so, for the git the following equivalent 
> > patch will be needed, after which the two versions shall be in sync again:
> > 
> > sh_mobile_ceu_camera: fix compile breakage, caused by a bad merge
> > 
> > Signed-off-by: Guennadi Liakhovetski 
> 
> So who wants to push this one? I'm planning on sending Linus updates
> shortly, so can roll this in with mine, as it seems to have missed the
> last v4l merge.

Paul,

It seems fine to me if you could do it. I have some pending stuff on other
kernel areas, so I'd appreciate if you can handle this fix.

You have my ack on it:

Acked-by: Mauro Carvalho Chehab 



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

Re: [PULL] soc-camera 2.6.32: new driver and a compile-fix

[Paul Mundt]

On Wed, Sep 23, 2009 at 06:02:04PM +0200, Guennadi Liakhovetski wrote:
> On Wed, 23 Sep 2009, Guennadi Liakhovetski wrote:
> 
> > Hi Mauro
> > 
> > The following two patches are for 2.6.32. One of them fixes 
> > sh_mobile_ceu_camera compile breakage, and another one adds a new 
> > soc-camera / v4l2-subdev driver for ov9640. Marek, looks like you didn't 
> > even compile tested your driver with CONFIG_VIDEO_ADV_DEBUG=y. It didn't 
> > compile, so, I had to fix it.
> > 
> > Please pull from http://linuxtv.org/hg/~gliakhovetski/v4l-dvb
> > 
> > for the following 2 changesets:
> > 
> > 01/02: V4L2: Add a v4l2-subdev (soc-camera) driver for OmniVision OV9640 
> > sensor
> > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=1dec51b360a3
> > 
> > 02/02: sh_mobile_ceu_camera: fix compile breakage, caused by a bad merge
> > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=a798c751f06d
> 
> Sorry, forgot to mention, somehow, the git and the hg versions got 
> different merges, both wrong, so, for the git the following equivalent 
> patch will be needed, after which the two versions shall be in sync again:
> 
> sh_mobile_ceu_camera: fix compile breakage, caused by a bad merge
> 
> Signed-off-by: Guennadi Liakhovetski 

So who wants to push this one? I'm planning on sending Linus updates
shortly, so can roll this in with mine, as it seems to have missed the
last v4l merge.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] tda18271_set_analog_params major bugfix

[spam]

On Thu, Sep 24, 2009 at 02:46:06PM -0400, Michael Krufky wrote:
> On Tue, Sep 22, 2009 at 5:05 PM,   wrote:
> >
> > Multiplication by 62500 causes an overflow in the 32 bits "freq" register 
> > when
> > using radio. FM radio reception on a Zolid Hybrid PCI is now working. Other
> > tda18271 configurations may also benefit from this change ;)
> >
> > Signed-off-by: henk.vergo...@gmail.com
> >
> > diff -r 29e4ba1a09bc linux/drivers/media/common/tuners/tda18271-fe.c
...
> > -   freq = freq / 1000;
> > +   freq = params->frequency * 625;
> > +   freq = freq / 10;

Hmm now that I review my own patch:

-   freq = freq / 1000;
+   freq = params->frequency * 125;
+   freq = freq / 2;

might even be better...

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

Re: [PATCH 4/4] Zolid Hybrid PCI card add AGC control

[spam]

On Thu, Sep 24, 2009 at 02:55:42PM -0400, Michael Krufky wrote:
> 
> Henk,
> 
> This is *very* interesting...  Have you taken a scope to the board to
> measure AGC interference?   This seems to be *very* similar to
> Hauppauge's design for the HVR1120 and HVR1150 boards, which are
> actually *not* based on any reference design.

Yes a scope would be nice!

No I traced some pins with a ohm meter. After some gpio togling and measuring
the voltage on the hc4052 I found out the s0 and s1 pins.

For the dvb reception I looked at the BER (bit-error-rate) using tzap it
seemed to drop from 8000 or so to 4000 when using gpio21 = 1.
Analog reception is a no-go in this mode it only works when gpio21 = 0.

FM radio seemed a (little) bit better when using fm_rfn = 0 and the
1.5Mhz antialiasing filter enabled. But its all somewhat subjective I
must admit.

> 
> I have no problems with this patch, but I would be interested to hear
> that you can prove it is actually needed by using a scope.  If you
> don't have a scope, I understand  but this certainly peaks my
> interest.
> 
> Do you have schematics of that board?

Nope, I will update the wiki with a few drawings that I have been able
to figure out.

Thanks for the support!

regards,
henk

BTW Currently the card is for sale in the Aldi for 28.99 euros if
someone is interested and in the proximity of Holland ;).

> 
--
To unsubscribe from this list: send the line "unsubscribe 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: [Linux-uvc-devel] [PATCH] uvc: kmalloc failure ignored in uvc_ctrl_add_ctrl()

[Laurent Pinchart]

On Thursday 24 September 2009 10:50:39 Paulo Assis wrote:
> Laurent,
> 
> > That's not enough to prevent a kernel crash. The driver can try to
> > dereference ctrl->data if ctrl->info isn't NULL. You should only set
> > ctrl->info if allocationg succeeds. Something like
> >
> >ctrl->data = kmalloc(ctrl->info->size * UVC_CTRL_NDATA,
> > GFP_KERNEL); if (ctrl->data == NULL)
> >return -ENOMEM;
> >
> >ctrl->info = info;
> 
> Without reading any code this doesn't seem correct, how can you use
> ctrl->info->size if you haven't set ctrl->info yet?
> 
> Did you mean something like this:
> 
>  ctrl->data = kmalloc(info->size * UVC_CTRL_NDATA, GFP_KERNEL);
>  if (ctrl->data == NULL)
>  return -ENOMEM;
> 
>  ctrl->info = info;
> 
> 
> Like I said I haven't read the code but this looks better.

Oops, you're right. My bad. Thanks for catching this.

-- 
Regards,

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

Re: [PATCH 4/4] Zolid Hybrid PCI card add AGC control

[Michael Krufky]

On Tue, Sep 22, 2009 at 5:09 PM,   wrote:
>
> Switches IF AGC control via GPIO 21 of the saa7134. Improves DTV reception and
> FM radio reception.
>
> Signed-off-by: henk.vergo...@gmail.com

Reviewed-by: Michael Krufky 

Henk,

This is *very* interesting...  Have you taken a scope to the board to
measure AGC interference?   This seems to be *very* similar to
Hauppauge's design for the HVR1120 and HVR1150 boards, which are
actually *not* based on any reference design.

I have no problems with this patch, but I would be interested to hear
that you can prove it is actually needed by using a scope.  If you
don't have a scope, I understand  but this certainly peaks my
interest.

Do you have schematics of that board?

Regards,

Mike Krufky

>
> diff -r 29e4ba1a09bc linux/drivers/media/video/saa7134/saa7134-cards.c
> --- a/linux/drivers/media/video/saa7134/saa7134-cards.c Sat Sep 19 09:45:22 
> 2009 -0300
> +++ b/linux/drivers/media/video/saa7134/saa7134-cards.c Tue Sep 22 22:06:31 
> 2009 +0200
> @@ -6651,6 +6651,22 @@
>        return 0;
>  }
>
> +static inline int saa7134_tda18271_zolid_toggle_agc(struct saa7134_dev *dev,
> +                                                     enum tda18271_mode mode)
> +{
> +       switch (mode) {
> +       case TDA18271_ANALOG:
> +               saa7134_set_gpio(dev, 21, 0);
> +               break;
> +       case TDA18271_DIGITAL:
> +               saa7134_set_gpio(dev, 21, 1);
> +               break;
> +       default:
> +               return -EINVAL;
> +       }
> +       return 0;
> +}
> +
>  static int saa7134_tda8290_18271_callback(struct saa7134_dev *dev,
>                                          int command, int arg)
>  {
> @@ -6663,7 +6679,8 @@
>                case SAA7134_BOARD_HAUPPAUGE_HVR1120:
>                        ret = saa7134_tda18271_hvr11x0_toggle_agc(dev, arg);
>                        break;
> -               default:
> +               case SAA7134_BOARD_ZOLID_HYBRID_PCI:
> +                       ret = saa7134_tda18271_zolid_toggle_agc(dev, arg);
>                        break;
>                }
>                break;
> @@ -6682,6 +6699,7 @@
>        switch (dev->board) {
>        case SAA7134_BOARD_HAUPPAUGE_HVR1150:
>        case SAA7134_BOARD_HAUPPAUGE_HVR1120:
> +       case SAA7134_BOARD_ZOLID_HYBRID_PCI:
>                /* tda8290 + tda18271 */
>                ret = saa7134_tda8290_18271_callback(dev, command, arg);
>                break;
> @@ -6985,6 +7003,11 @@
>                saa_andorl(SAA7134_GPIO_GPMODE0 >> 2,   0x8000, 
> 0x8000);
>                saa_andorl(SAA7134_GPIO_GPSTATUS0 >> 2, 0x8000, 
> 0x8000);
>                break;
> +       case SAA7134_BOARD_ZOLID_HYBRID_PCI:
> +               saa7134_set_gpio(dev, 21, 0);   /* s0 HC4052 */
> +               saa7134_set_gpio(dev, 22, 0);   /* vsync tda18271 - TODO 
> implement saa713x driven sync in analog TV modes */
> +               saa7134_set_gpio(dev, 23, 0);   /* s1 HC4052 */
> +               break;
>        }
>        return 0;
>  }
> diff -r 29e4ba1a09bc linux/drivers/media/video/saa7134/saa7134-dvb.c
> --- a/linux/drivers/media/video/saa7134/saa7134-dvb.c   Sat Sep 19 09:45:22 
> 2009 -0300
> +++ b/linux/drivers/media/video/saa7134/saa7134-dvb.c   Tue Sep 22 22:06:31 
> 2009 +0200
> @@ -1026,8 +1026,17 @@
>        .disable_gate_access = 1,
>  };
>
> +static struct tda18271_std_map zolid_tda18271_std_map = {
> +       /* FM reception via RF_IN */
> +       .fm_radio = { .if_freq = 1250, .fm_rfn = 0, .agc_mode = 3, .std = 0,
> +                     .if_lvl = 0, .rfagc_top = 0x2c, },
> +};
> +
>  static struct tda18271_config zolid_tda18271_config = {
> +       .std_map = &zolid_tda18271_std_map,
>        .gate    = TDA18271_GATE_ANALOG,
> +       .config  = 3,
> +       .output_opt = TDA18271_OUTPUT_LT_OFF,
>  };
>
>  /* ==
> --
> To unsubscribe from this list: send the line "unsubscribe 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 3/4] tda8290 enable deemphasis_50 module parameter.

[Michael Krufky]

On Tue, Sep 22, 2009 at 5:07 PM,   wrote:
>
> This adds a forgotten module_param macro needed to set a deemphasis of 50us.
> It is the standard setting for commercial FM radio broadcasts outside the US.
>
> Signed-off-by: henk.vergo...@gmail.com
>
> diff -r 29e4ba1a09bc linux/drivers/media/common/tuners/tda8290.c
> --- a/linux/drivers/media/common/tuners/tda8290.c       Sat Sep 19 09:45:22 
> 2009 -0300
> +++ b/linux/drivers/media/common/tuners/tda8290.c       Tue Sep 22 22:06:31 
> 2009 +0200
> @@ -34,6 +34,7 @@
>  MODULE_PARM_DESC(debug, "enable verbose debug messages");
>
>  static int deemphasis_50;
> +module_param(deemphasis_50, int, 0644);
>  MODULE_PARM_DESC(deemphasis_50, "0 - 75us deemphasis; 1 - 50us deemphasis");
>
>  /* -- */
>

Reviewed-by: Michael Krufky 

Mauro, this patch is OK to merge ASAP -- if it's not merged already by
the time I have the tda18271 fixes ready, then I'll send this to you
in the same pull request.

Thanks for this fix, Henk.

Regards,

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

Re: [PATCH 1/4] tda18271_set_analog_params major bugfix

[Michael Krufky]

On Tue, Sep 22, 2009 at 5:05 PM,   wrote:
>
> Multiplication by 62500 causes an overflow in the 32 bits "freq" register when
> using radio. FM radio reception on a Zolid Hybrid PCI is now working. Other
> tda18271 configurations may also benefit from this change ;)
>
> Signed-off-by: henk.vergo...@gmail.com
>
> diff -r 29e4ba1a09bc linux/drivers/media/common/tuners/tda18271-fe.c
> --- a/linux/drivers/media/common/tuners/tda18271-fe.c   Sat Sep 19 09:45:22 
> 2009 -0300
> +++ b/linux/drivers/media/common/tuners/tda18271-fe.c   Tue Sep 22 22:06:31 
> 2009 +0200
> @@ -1001,38 +1020,43 @@
>        struct tda18271_std_map_item *map;
>        char *mode;
>        int ret;
> -       u32 freq = params->frequency * 62500;
> +       u32 freq;
>
>        priv->mode = TDA18271_ANALOG;
>
>        if (params->mode == V4L2_TUNER_RADIO) {
> -               freq = freq / 1000;
> +               freq = params->frequency * 625;
> +               freq = freq / 10;
>                map = &std_map->fm_radio;
>                mode = "fm";
> -       } else if (params->std & V4L2_STD_MN) {
> -               map = &std_map->atv_mn;
> -               mode = "MN";
> -       } else if (params->std & V4L2_STD_B) {
> -               map = &std_map->atv_b;
> -               mode = "B";
> -       } else if (params->std & V4L2_STD_GH) {
> -               map = &std_map->atv_gh;
> -               mode = "GH";
> -       } else if (params->std & V4L2_STD_PAL_I) {
> -               map = &std_map->atv_i;
> -               mode = "I";
> -       } else if (params->std & V4L2_STD_DK) {
> -               map = &std_map->atv_dk;
> -               mode = "DK";
> -       } else if (params->std & V4L2_STD_SECAM_L) {
> -               map = &std_map->atv_l;
> -               mode = "L";
> -       } else if (params->std & V4L2_STD_SECAM_LC) {
> -               map = &std_map->atv_lc;
> -               mode = "L'";
>        } else {
> -               map = &std_map->atv_i;
> -               mode = "xx";
> +               freq = params->frequency * 62500;
> +
> +               if (params->std & V4L2_STD_MN) {
> +                       map = &std_map->atv_mn;
> +                       mode = "MN";
> +               } else if (params->std & V4L2_STD_B) {
> +                       map = &std_map->atv_b;
> +                       mode = "B";
> +               } else if (params->std & V4L2_STD_GH) {
> +                       map = &std_map->atv_gh;
> +                       mode = "GH";
> +               } else if (params->std & V4L2_STD_PAL_I) {
> +                       map = &std_map->atv_i;
> +                       mode = "I";
> +               } else if (params->std & V4L2_STD_DK) {
> +                       map = &std_map->atv_dk;
> +                       mode = "DK";
> +               } else if (params->std & V4L2_STD_SECAM_L) {
> +                       map = &std_map->atv_l;
> +                       mode = "L";
> +               } else if (params->std & V4L2_STD_SECAM_LC) {
> +                       map = &std_map->atv_lc;
> +                       mode = "L'";
> +               } else {
> +                       map = &std_map->atv_i;
> +                       mode = "xx";
> +               }
>        }
>
>        tda_dbg("setting tda18271 to system %s\n", mode);
>

Nice catch, Henk -- Thank you for this fix...  I will have this one
merged as soon as I can.

Signed-off-by: Michael Krufky 

Mauro, please do not merge the tda18271 / tda829x patches until I send
you a pull request -- there is a patch-order dependency with other
pending changes and I would prefer to send this to you in the proper
order.

Thanks,

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

Re: [PATCH 2/4] 18271_calc_main_pll small bugfix

[Michael Krufky]

On Tue, Sep 22, 2009 at 5:06 PM,   wrote:
>
> Removed code fragment that is not part of the (C2) specs. Possibly an early
> remnant of an attempted if_notch filter configuration. It is already
> handled correctly in the tda18271_set_if_notch function.
>
> Signed-off-by: henk.vergo...@gmail.com
>
> diff -r 29e4ba1a09bc linux/drivers/media/common/tuners/tda18271-common.c
> --- a/linux/drivers/media/common/tuners/tda18271-common.c       Sat Sep 19 
> 09:45:22 2009 -0300
> +++ b/linux/drivers/media/common/tuners/tda18271-common.c       Tue Sep 22 
> 22:06:31 2009 +0200
> @@ -582,15 +582,6 @@
>
>        regs[R_MPD]   = (0x77 & pd);
>
> -       switch (priv->mode) {
> -       case TDA18271_ANALOG:
> -               regs[R_MPD]  &= ~0x08;
> -               break;
> -       case TDA18271_DIGITAL:
> -               regs[R_MPD]  |=  0x08;
> -               break;
> -       }
> -
>        div =  ((d * (freq / 1000)) << 7) / 125;
>
>        regs[R_MD1]   = 0x7f & (div >> 16);
>


NACK.  This bit needs to remain -- do not merge this.

Regards,

Mike Krufky
--
To unsubscribe from this list: send the line "unsubscribe 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: New device: Dikom DK-300 (maybe Kworld 323U rebranded)

[xwang1976]

The rapidshare link is no more accessible.
Do you want me to put that file online again?
Xwang

xwang1...@email.it ha scritto:

Is there any news?
Xwang

xwang1...@email.it ha scritto:

Hi to all,
I would like to know if the usbsnoop I have done under windows xp is 
ok or if, otherwise, I have to do something different when opening the 
video application under windows xp (I've opened it in analogical mode. 
Should I open it also in digital tv mode?).

Till sunday I can take usbsnoopes of the device using my brother pc.
After such date I've to wait two weeks.
Thank you,
Xwang

xwang1...@email.it ha scritto:

This is the link to the usbsnoop I've done under windows xp:
http://rapidshare.com/files/267432234/UsbSnoop2.zip.html
I hope it is useful to:
1) understand if the dikom DK-300 is really a rebranded kworld 323u
2)resolve the analog tv issues (kernel panic while scanning channels 
and absence of audio)

Thank you,
Xwang

xwang1...@email.it ha scritto:
I forgot to send the dmesg I have had using the latest kernel 
(dmesg_dikom-dk300.txt) and the Dainius modified one 
(dmesg_dikom-dk300-mod.txt).

Xwang

xwang1...@email.it ha scritto:

Hi to all!
I've bought this device because I've seen that it has a better 
digital tuner when compared with my empire dual pen usb device.
It does not work with the latest driver because there is no digital 
tv while analog tv works with audio (even if it is a bit noisy) 
using the start script I have attached, but when I search for 
analog tv channels using tvtime-scanner, the system hangs and I 
have to turn it off being alt+sys+REISUB unable to reboot the machine.
If I modify the driver as suggest by Dainius, the digital tv works 
perfectly, but analog audio disappears and the hangs when tuning 
analog channels persist.
Can you help me so that to have this device fully functional (I'll 
continue to test also the Empire one, but this is better)?
If you need it I can take an usbsnoop of the same device, but I 
don't know how to use it exactly.

I'll search if I find some howto.
Thank you,
Xwang

Dainius Ridzevicius ha scritto:

Hi,

replace files in /v4l-dvb/linux/drivers/media/video/em28xx
with attached ones and make all v4l-dvb.
make && make install. Reboot to clean old modules.

DVB-T on kwordl 323ur is working, watching TV for an hour now.

regards,


On Thu, Aug 13, 2009 at 4:22 PM, > wrote:


Yes,
I'm still interested.
I suppose it is the same device.
In the next days I hope I will be able to take an usbsnoop of the
device under windows xp.
Meantime, I would like to test your drive.
Regards,
Xwang

Dainius Ridzevicius ha scritto:

Hello,

I have got Kworld 323UR hybrid tuner and managed to get dvb-t
lock today, will do some more testing later, but I can email
or post you a link for v4l-dvb sources changed by me (from
todays mercurial) if You are still interested.

Regards,
Dainius


-- -




--
-

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


--
To unsubscribe from this list: send the line "unsubscribe 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: V4L-DVB Summit Day 1

[Guennadi Liakhovetski]

Hi Hans

Thanks for keeping us updated. One comment:

On Wed, 23 Sep 2009, Hans Verkuil wrote:

> In the afternoon we discussed the proposed timings API. There was no 
> opposition to this API. The idea I had to also use this for sensor setup 
> turned out to be based on a misconception on how the S_FMT relates to 
> sensors. 
> ENUM_FRAMESIZES basically gives you the possible resolutions that the scaler 
> hidden inside the bridge can scale the native sensor resolution. It does not 
> enumerate the various native sensor resolutions, since there is only one. So 
> S_FMT really sets up the scaler.

Just as Jinlu Yu noticed in his email, this doesn't reflect the real 
situation, I am afraid. You can use binning and skipping on the sensor to 
scale the image, and you can also use the bridge to do the scaling, as you 
say. Worth than that, there's also a case, where there _several_ ways to 
perform scaling on the sensor, among which one can freely choose, and the 
host can scale too. And indeed it makes sense to scale on the source to 
save the bandwidth and thus increase the framerate. So, what I'm currently 
doing on sh-mobile, I try to scale on the client - in the best possible 
way. And then use bridge scaling to provide the exact result.

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

[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS

[Hans Verkuil]

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

Results of the daily build of v4l-dvb:

date:Thu Sep 24 19:00:03 CEST 2009
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   13041:a798c751f06d
gcc version: gcc (GCC) 4.3.1
hardware:x86_64
host os: 2.6.26

linux-2.6.22.19-armv5: OK
linux-2.6.23.12-armv5: OK
linux-2.6.24.7-armv5: OK
linux-2.6.25.11-armv5: OK
linux-2.6.26-armv5: OK
linux-2.6.27-armv5: OK
linux-2.6.28-armv5: OK
linux-2.6.29.1-armv5: OK
linux-2.6.30-armv5: OK
linux-2.6.31-armv5: OK
linux-2.6.27-armv5-ixp: ERRORS
linux-2.6.28-armv5-ixp: ERRORS
linux-2.6.29.1-armv5-ixp: ERRORS
linux-2.6.30-armv5-ixp: ERRORS
linux-2.6.31-armv5-ixp: ERRORS
linux-2.6.28-armv5-omap2: OK
linux-2.6.29.1-armv5-omap2: OK
linux-2.6.30-armv5-omap2: OK
linux-2.6.31-armv5-omap2: ERRORS
linux-2.6.22.19-i686: ERRORS
linux-2.6.23.12-i686: ERRORS
linux-2.6.24.7-i686: ERRORS
linux-2.6.25.11-i686: ERRORS
linux-2.6.26-i686: OK
linux-2.6.27-i686: OK
linux-2.6.28-i686: OK
linux-2.6.29.1-i686: WARNINGS
linux-2.6.30-i686: WARNINGS
linux-2.6.31-i686: WARNINGS
linux-2.6.23.12-m32r: OK
linux-2.6.24.7-m32r: OK
linux-2.6.25.11-m32r: OK
linux-2.6.26-m32r: OK
linux-2.6.27-m32r: OK
linux-2.6.28-m32r: OK
linux-2.6.29.1-m32r: OK
linux-2.6.30-m32r: OK
linux-2.6.31-m32r: OK
linux-2.6.30-mips: WARNINGS
linux-2.6.31-mips: OK
linux-2.6.27-powerpc64: ERRORS
linux-2.6.28-powerpc64: ERRORS
linux-2.6.29.1-powerpc64: ERRORS
linux-2.6.30-powerpc64: ERRORS
linux-2.6.31-powerpc64: ERRORS
linux-2.6.22.19-x86_64: ERRORS
linux-2.6.23.12-x86_64: ERRORS
linux-2.6.24.7-x86_64: ERRORS
linux-2.6.25.11-x86_64: ERRORS
linux-2.6.26-x86_64: OK
linux-2.6.27-x86_64: OK
linux-2.6.28-x86_64: OK
linux-2.6.29.1-x86_64: WARNINGS
linux-2.6.30-x86_64: WARNINGS
linux-2.6.31-x86_64: WARNINGS
sparse (linux-2.6.31): OK
linux-2.6.16.61-i686: ERRORS
linux-2.6.17.14-i686: ERRORS
linux-2.6.18.8-i686: ERRORS
linux-2.6.19.5-i686: ERRORS
linux-2.6.20.21-i686: ERRORS
linux-2.6.21.7-i686: ERRORS
linux-2.6.16.61-x86_64: ERRORS
linux-2.6.17.14-x86_64: ERRORS
linux-2.6.18.8-x86_64: ERRORS
linux-2.6.19.5-x86_64: ERRORS
linux-2.6.20.21-x86_64: ERRORS
linux-2.6.21.7-x86_64: ERRORS

Detailed results are available here:

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

Full logs are available here:

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

The V4L2 specification failed to build, but the last compiled spec is here:

http://www.xs4all.nl/~hverkuil/spec/v4l2.html

The DVB API specification from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf

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

[RESEND PULL] http://udev.netup.ru/hg/v4l-dvb-aospan

[Abylai Ospan]

Mauro,

Please pulll changes from:
http://udev.netup.ru/hg/v4l-dvb-aospan/rev/711d9630876f


Show speed of transport stream in Kbit/sec:

for example, data obtained from DVB-S2 transponder from Eutelsat W4:
Jun 27 12:06:01 udev TS speed 58608 Kbits/sec
Jun 27 12:06:03 udev TS speed 58422 Kbits/sec
Jun 27 12:06:04 udev TS speed 58608 Kbits/sec

for DVB-S1 transponder from the same satellite:
Jun 27 12:07:00 udev TS speed 37108 Kbits/sec
Jun 27 12:07:02 udev TS speed 37089 Kbits/sec
Jun 27 12:07:04 udev TS speed 37202 Kbits/sec

this feature can be enabled using following command:
"echo 1 > /sys/module/dvb_core/parameters/dvb_demux_speedcheck"

and disabled by following command:
"echo 0 > /sys/module/dvb_core/parameters/dvb_demux_speedcheck"

-- 
Abylai Ospan 
NetUP Inc.

--
To unsubscribe from this list: send the line "unsubscribe 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] http://www.linuxtv.org/hg/~dougsland/v4l-dvb

[Douglas Schilling Landgraf]

Hello Mauro,

   Please pull from http://www.linuxtv.org/hg/~dougsland/v4l-dvb for
the following:

- radio-mr800: set radio frequency only upon success
- radio-mr800: simplify device warnings
- radio-mr800: preserve radio state during suspend/resume
- radio-mr800: fix behavior of set_stereo function
- radio-mr800: ensure the radio is initialized to a consistent state
- radio-mr800: remove device initialization from open/close
- radio-mr800: fix potential use after free
- radio-mr800: remove device removed indicator
- radio-mr800: simplify locking in ioctl callbacks
- radio-mr800: simplify access to amradio_device
- radio-mr800: remove unnecessary local variable
- radio-mr800: simplify error paths in usb probe callback
- radio-mr800: simplify video_device allocation
- radio-mr800: implement proper locking

Thanks,
Douglas
--
To unsubscribe from this list: send the line "unsubscribe 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: V4L-DVB Summit Day 1

[Yu, Jinlu]

About S_FMT, Moorestown Camera driver which I am working on has a different 
story.

We do use different sensor resolutions, because high resolution has low FPS, 
and can not be used for view-finding, e.g. ov5630 only output 15fps with 5Mega 
resolution. 

Our current solution is to disable the scaler in ISP and only support the 
resolutions that sensor can provide. So S_FMT will set the framesize into 
sensor.

Best Regards
Jinlu Yu
UMG UPSG PRC
INET: 8758 1603
TEL:  86 10 8217 1603
FAX:  86 10 8286 1400

-Original Message-
From: linux-media-ow...@vger.kernel.org 
[mailto:linux-media-ow...@vger.kernel.org] On Behalf Of Hans Verkuil
Sent: 2009年9月24日 13:39
To: linux-media@vger.kernel.org
Subject: V4L-DVB Summit Day 1

Hi all,

As most of you know I organized a v4l-dvb summit (well, really a v4l2 summit 
as there were no dvb topics to discuss) during the Linux Plumbers Conference 
in Portland. This summit will take all three days of this conference, and I 
intend to make a short report at the end of each day.

First of all I want to thank everyone who attended this first day of the 
summit: we had a great turn-out with seven core v4l-dvb developers, three TI 
engineers, two Nokia engineers, two engineers from Samsung and an Intel 
engineer. I know I've forgotten someone, I'll try to fix that tomorrow.

But it meant that the main SoC vendors with complex video hardware were well 
represented.

The summit started off with an overview of the proposed media controller and 
an overview of the features of several SoCs to give an idea of what sort of 
complexity has to be supported in the future. I'll try to get some of the 
presentations up on my site. Unfortunately, not all presentations can be made 
public. The main message that came across though is that these complex devices 
with big pipelines, scalers, composers, colorspace converters, etc. require a 
completely new way of working.

While we did discuss the concepts of the media controller, we did not go into 
much detail: that is scheduled for Thursday.

In the afternoon we discussed the proposed timings API. There was no 
opposition to this API. The idea I had to also use this for sensor setup 
turned out to be based on a misconception on how the S_FMT relates to sensors. 
ENUM_FRAMESIZES basically gives you the possible resolutions that the scaler 
hidden inside the bridge can scale the native sensor resolution. It does not 
enumerate the various native sensor resolutions, since there is only one. So 
S_FMT really sets up the scaler.

So we can proceed with the timings RFC and hopefully have this implemented for 
2.6.33.

Next was the event API proposal: this caused some more discussions, in 
particular since the original RFC had no provision for (un)subscribing to 
events. The idea is that we want to subscribe to events on a per-filehandle 
basis. The core framework can keep track of events and distribute them to 
filehandles that 'listen' to them. So this RFC will clearly need to go to at 
least one revision.

That was also a good point to stop for the day and head out to get free beer 
and food :-)

Scheduled for Thursday is a discussion of the proposed memory pool and 
continued media controller discussions.

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
N�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{���bj)��骅w*jg�报�茛j/�赇z罐���2���ㄨ��&�)摺�a囤���G���h��j:+v���w��佶

Re: [PATCH 0/5] V4L2 patches for Intel Moorestown Camera Imaging

[Mauro Carvalho Chehab]

Em Thu, 24 Sep 2009 19:21:40 +0800
"Yu, Jinlu"  escreveu:

> Hi, Hans/Guennadi
> 
> I am modifying these drivers to comply with v4l2 framework. I have finished 
> replacing our buffer managing code with utility function from videobuf-core.c 
> and videobuf-dma-contig.c. Now I am working on the subdev. One thing I am 
> sure is that each sensor should be registered as a v4l2_subdev and ISP (Image 
> Signal Processor) is registered as a v4l2_device acting as the bridge device. 
> 
> But we have two ways to deal with the relationship of sensor and ISP, and we 
> don't know which one is better. Could you help me on this?
> 
> No.1. Register the ISP as a video_device (/dev/video0) and treat each of the 
> sensor (SOC and RAW) as an input of the ISP. If I want to change the sensor, 
> use the VIDIOC_S_INPUT to change input from sensor A to sensor B. But I have 
> a concern about this ioctl. Since I didn't find any code related HW pipeline 
> status checking and HW register setting in the implement of this ioctl (e.g. 
> vino_s_input in /drivers/media/video/vino.c). So don't I have to stream-off 
> the HW pipeline and change the HW register setting for the new input? Or is 
> it application's responsibility to stream-off the pipeline and renegotiate 
> the parameters for the new input?
> 
> No.2. Combine the SOC sensor together with the ISP as Channel One and 
> register it as /dev/video0, and combine the RAW sensor together with the ISP 
> as Channel Two and register it as /dev/video1. Surely, only one channel works 
> at a certain time due to HW restriction. When I want to change the sensor 
> (e.g. from SOC sensor to RAW sensor), just close /dev/video0 and open 
> /dev/video1.

The better seems to be No. 1. As you need to re-negotiate parameters for
switching from one sensor to another, if some app tries to change from one
input to another while streaming, you should just return -EBUSY, if it is not
possible to switch (for example, if the selected format/resolution/frame rate
is incompatible).



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

Re: [PATCH 0/5] V4L2 patches for Intel Moorestown Camera Imaging

[Yu, Jinlu]

Hi, Hans/Guennadi

I am modifying these drivers to comply with v4l2 framework. I have finished 
replacing our buffer managing code with utility function from videobuf-core.c 
and videobuf-dma-contig.c. Now I am working on the subdev. One thing I am sure 
is that each sensor should be registered as a v4l2_subdev and ISP (Image Signal 
Processor) is registered as a v4l2_device acting as the bridge device. 

But we have two ways to deal with the relationship of sensor and ISP, and we 
don't know which one is better. Could you help me on this?

No.1. Register the ISP as a video_device (/dev/video0) and treat each of the 
sensor (SOC and RAW) as an input of the ISP. If I want to change the sensor, 
use the VIDIOC_S_INPUT to change input from sensor A to sensor B. But I have a 
concern about this ioctl. Since I didn't find any code related HW pipeline 
status checking and HW register setting in the implement of this ioctl (e.g. 
vino_s_input in /drivers/media/video/vino.c). So don't I have to stream-off the 
HW pipeline and change the HW register setting for the new input? Or is it 
application's responsibility to stream-off the pipeline and renegotiate the 
parameters for the new input?

No.2. Combine the SOC sensor together with the ISP as Channel One and register 
it as /dev/video0, and combine the RAW sensor together with the ISP as Channel 
Two and register it as /dev/video1. Surely, only one channel works at a certain 
time due to HW restriction. When I want to change the sensor (e.g. from SOC 
sensor to RAW sensor), just close /dev/video0 and open /dev/video1.

Best Regards
Jinlu Yu
Intel China Research Center

>-Original Message-
>From: linux-media-ow...@vger.kernel.org
>[mailto:linux-media-ow...@vger.kernel.org] On Behalf Of Hans Verkuil
>Sent: Saturday, May 02, 2009 11:43 PM
>To: Guennadi Liakhovetski
>Cc: Zhang, Xiaolin; linux-media@vger.kernel.org; Johnson, Charles F; Zhu, 
>Daniel
>Subject: Re: [PATCH 0/5] V4L2 patches for Intel Moorestown Camera Imaging
>Drivers
>
>On Friday 01 May 2009 23:26:02 Guennadi Liakhovetski wrote:
>> On Thu, 30 Apr 2009, Zhang, Xiaolin wrote:
>> > Hi All,
>> >
>> > Here is the a set of V4L2 camera sensors and ISP drivers to support the
>> > Intel Moorestown camera imaging subsystem. The Camera Imaging interface
>> > in Moorestown is responsible for capturing both still and video frames.
>> > The CI handles demosaicing, color synthesis, filtering, image
>> > enhancement functions and JPEG encode. Intel Moorestown platform can
>> > support either a single camera or two cameras. A platform with two
>> > cameras will have on the same side as this display and the second on
>> > the opposite side the display. The camera on the display side will be
>> > used for video conferencing (with low resolution SoC cameras) and the
>> > other camera is used to still image capture or video recode (with high
>> > resolution RAW cameras).
>> >
>> > In this set of driver patches, I will submit the 5 patches to enable
>> > the ISP HW and 3 cameras module (two SoCs: 1.3MP - Omnivision 9665, 2MP
>> > - Omnivison 2650 and one RAW: 5MP - Omnivision 5630).
>> > 1. Intel Moorestown ISP driver.
>> > 2. Intel Moorestown camera sensor pseudo driver. This is to uniform the
>> > interfaces for ISP due to supporting dual cameras.
>> > 3. Intel Moorestown 2MP camera sensor driver.
>> > 4. Intel Moorestown 5MP camera sensor driver.
>> > 5. Intel Moorestown 1.3MP camera sensor driver.
>> >
>> > I will post the above 5 patches in near feature.
>>
>> I think this is a perfect candidate for the use of the v4l2-(sub)dev API,
>> and should be converted to use it, am I right?
>
>Absolutely. The sensor drivers must use v4l2_subdev, otherwise they will not
>be reusable by other drivers.
>
>There is a lot of work that needs to be done before these sensor drivers can
>be merged. These sensor drivers are tightly coupled to the platform driver,
>thus preventing any reuse of these i2c devices. That's bad and something
>that needs to be fixed first.
>
>Xiaolin, please take a look at Documentation/video4linux/v4l2-framework.txt
>for information on the new v4l2 framework. All v4l2 i2c drivers should use
>v4l2_subdev to enable reuse of these i2c devices in other platform drivers
>and webcams.
>
>Regards,
>
>   Hans
>
>>
>> Thanks
>> Guennadi
>> ---
>> Guennadi Liakhovetski, Ph.D.
>> Freelance Open-Source Software Developer
>> http://www.open-technology.de/
>
>
>
>--
>Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
>--
>To unsubscribe from this list: send the line "unsubscribe linux-media" in
>the body of a message to majord...@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] atoi: Drop custom atoi from drivers/video/modedb.c

[Andy Shevchenko]

From: Andy Shevchenko 

Kernel has simple_strtol() implementation which could be used as atoi().

Signed-off-by: Andy Shevchenko 
---
 drivers/video/modedb.c |   24 +---
 1 files changed, 5 insertions(+), 19 deletions(-)

diff --git a/drivers/video/modedb.c b/drivers/video/modedb.c
index 34e4e79..0129f1b 100644
--- a/drivers/video/modedb.c
+++ b/drivers/video/modedb.c
@@ -13,6 +13,7 @@
 
 #include 
 #include 
+#include 
 
 #undef DEBUG
 
@@ -402,21 +403,6 @@ const struct fb_videomode vesa_modes[] = {
 EXPORT_SYMBOL(vesa_modes);
 #endif /* CONFIG_FB_MODE_HELPERS */
 
-static int my_atoi(const char *name)
-{
-int val = 0;
-
-for (;; name++) {
-   switch (*name) {
-   case '0' ... '9':
-   val = 10*val+(*name-'0');
-   break;
-   default:
-   return val;
-   }
-}
-}
-
 /**
  * fb_try_mode - test a video mode
  * @var: frame buffer user defined part of display
@@ -539,7 +525,7 @@ int fb_find_mode(struct fb_var_screeninfo *var,
namelen = i;
if (!refresh_specified && !bpp_specified &&
!yres_specified) {
-   refresh = my_atoi(&name[i+1]);
+   refresh = simple_strtol(&name[i+1], NULL, 10);
refresh_specified = 1;
if (cvt || rb)
cvt = 0;
@@ -549,7 +535,7 @@ int fb_find_mode(struct fb_var_screeninfo *var,
case '-':
namelen = i;
if (!bpp_specified && !yres_specified) {
-   bpp = my_atoi(&name[i+1]);
+   bpp = simple_strtol(&name[i+1], NULL, 10);
bpp_specified = 1;
if (cvt || rb)
cvt = 0;
@@ -558,7 +544,7 @@ int fb_find_mode(struct fb_var_screeninfo *var,
break;
case 'x':
if (!yres_specified) {
-   yres = my_atoi(&name[i+1]);
+   yres = simple_strtol(&name[i+1], NULL, 10);
yres_specified = 1;
} else
goto done;
@@ -586,7 +572,7 @@ int fb_find_mode(struct fb_var_screeninfo *var,
}
}
if (i < 0 && yres_specified) {
-   xres = my_atoi(name);
+   xres = simple_strtol(name, NULL, 10);
res_specified = 1;
}
 done:
-- 
1.5.6.5

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

[PATCH 1/2] media: video: pwc: Use kernel's simple_strtol()

[Andy Shevchenko]

From: Andy Shevchenko 

Change own implementation of pwc_atoi() by simple_strtol(x, NULL, 10).

Signed-off-by: Andy Shevchenko 
Acked-by: Pekka Enberg 
---
 drivers/media/video/pwc/pwc-if.c |   23 +++
 1 files changed, 7 insertions(+), 16 deletions(-)

diff --git a/drivers/media/video/pwc/pwc-if.c b/drivers/media/video/pwc/pwc-if.c
index f976df4..89b620f 100644
--- a/drivers/media/video/pwc/pwc-if.c
+++ b/drivers/media/video/pwc/pwc-if.c
@@ -68,6 +68,7 @@
 #endif
 #include 
 #include 
+#include   /* simple_strtol() */
 
 #include "pwc.h"
 #include "pwc-kiara.h"
@@ -1916,19 +1917,6 @@ disconnect_out:
unlock_kernel();
 }
 
-/* *grunt* We have to do atoi ourselves :-( */
-static int pwc_atoi(const char *s)
-{
-   int k = 0;
-
-   k = 0;
-   while (*s != '\0' && *s >= '0' && *s <= '9') {
-   k = 10 * k + (*s - '0');
-   s++;
-   }
-   return k;
-}
-
 
 /*
  * Initialization code & module stuff
@@ -2078,13 +2066,16 @@ static int __init usb_pwc_init(void)
}
else {
/* No type or serial number specified, 
just a number. */
-   device_hint[i].device_node = 
pwc_atoi(s);
+   device_hint[i].device_node =
+   simple_strtol(s, NULL, 10);
}
}
else {
/* There's a colon, so we have at least a type 
and a device node */
-   device_hint[i].type = pwc_atoi(s);
-   device_hint[i].device_node = pwc_atoi(colon + 
1);
+   device_hint[i].type =
+   simple_strtol(s, NULL, 10);
+   device_hint[i].device_node =
+   simple_strtol(colon + 1, NULL, 10);
if (*dot != '\0') {
/* There's a serial number as well */
int k;
-- 
1.5.6.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

PULL request - http://kernellabs.com/hg/~pboettcher/v4l-dvb/

[Patrick Boettcher]

Hi Mauro,

please pull from

http://kernellabs.com/hg/~pboettcher/v4l-dvb/

for
- DiB7000P: improve rebostness of HAS_LOCK indicator
- DiB0070: if module is not built, don't say function is extern
- DIB0700: fix-up USB device ID for Terratec/Leadtek
- dib8000: SNR in 10th of dB

all of it should go for 2.6.32.

thanks
Patrick.
--
To unsubscribe from this list: send the line "unsubscribe 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: [Linux-uvc-devel] [PATCH] uvc: kmalloc failure ignored in uvc_ctrl_add_ctrl()

[Paulo Assis]

Laurent,


> That's not enough to prevent a kernel crash. The driver can try to dereference
> ctrl->data if ctrl->info isn't NULL. You should only set ctrl->info if
> allocationg succeeds. Something like
>
>        ctrl->data = kmalloc(ctrl->info->size * UVC_CTRL_NDATA, GFP_KERNEL);
>        if (ctrl->data == NULL)
>                return -ENOMEM;
>
>        ctrl->info = info;

Without reading any code this doesn't seem correct, how can you use
ctrl->info->size if you haven't set ctrl->info yet?

Did you mean something like this:

 ctrl->data = kmalloc(info->size * UVC_CTRL_NDATA, GFP_KERNEL);
 if (ctrl->data == NULL)
 return -ENOMEM;

 ctrl->info = info;


Like I said I haven't read the code but this looks better.

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