Message ID | 1381952506-2405-1-git-send-email-fschaefer.oss@googlemail.com (mailing list archive) |
---|---|
State | Superseded, archived |
Headers |
Received: from mail.tu-berlin.de ([130.149.7.33]) by www.linuxtv.org with esmtp (Exim 4.72) (envelope-from <linux-media-owner@vger.kernel.org>) id 1VWWyR-0001G5-QV; Wed, 16 Oct 2013 21:41:39 +0200 X-tubIT-Incoming-IP: 209.132.180.67 Received: from vger.kernel.org ([209.132.180.67]) by mail.tu-berlin.de (exim-4.72/mailfrontend-6) with esmtp id 1VWWyP-0007VS-5u; Wed, 16 Oct 2013 21:41:39 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760455Ab3JPTlg (ORCPT <rfc822;mkrufky@linuxtv.org> + 1 other); Wed, 16 Oct 2013 15:41:36 -0400 Received: from mail-ee0-f54.google.com ([74.125.83.54]:35216 "EHLO mail-ee0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756222Ab3JPTlf (ORCPT <rfc822;linux-media@vger.kernel.org>); Wed, 16 Oct 2013 15:41:35 -0400 Received: by mail-ee0-f54.google.com with SMTP id e53so601552eek.41 for <linux-media@vger.kernel.org>; Wed, 16 Oct 2013 12:41:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :content-transfer-encoding; bh=/5NKp7beyiW2oX0KJwcuTXbD36QcTo+RTEFK9OZ7NpU=; b=kl3OCFCC1ygdxiRLbFGOw6ufjJi+yNj6uA62onH6L0laxg/80z6jSmbPglMZ5nGcXL SmrHfI0FkcJ2aZwvxKAsn8EIkECknkQEUjlwJDLWjRmcV8JMM6UETRowy4GsymQkxUw1 Qqcn6dS8bjrdMtwqR/DXad7cGaFwrfDIe/cO4LNKOrdZP3KiAGMtjAIkIrIb/DoneQ3A cULprX1sgQEXXjpGGZy/JLyGr7mxnJAYLfQqHJy5JUZEphzZLGQwEx+Hii4L9Y2QQaUW Fsq9ginLeIx3eN1wMW7NB325vtmuRwecQgZr4x8uCpDz4/skFze1dSdJDsH0I6kgZxEx Y1IA== X-Received: by 10.14.212.72 with SMTP id x48mr7189946eeo.0.1381952494286; Wed, 16 Oct 2013 12:41:34 -0700 (PDT) Received: from Athlon64X2-5000.site (ip-178-201-166-65.unitymediagroup.de. [178.201.166.65]) by mx.google.com with ESMTPSA id e47sm5242594eeo.8.1969.12.31.16.00.00 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Oct 2013 12:41:33 -0700 (PDT) From: =?UTF-8?q?Frank=20Sch=C3=A4fer?= <fschaefer.oss@googlemail.com> To: m.chehab@samsung.com Cc: linux-media@vger.kernel.org, =?UTF-8?q?Frank=20Sch=C3=A4fer?= <fschaefer.oss@googlemail.com> Subject: [PATCH] em28xx: make sure that all subdevices are powered on when needed Date: Wed, 16 Oct 2013 21:41:46 +0200 Message-Id: <1381952506-2405-1-git-send-email-fschaefer.oss@googlemail.com> X-Mailer: git-send-email 1.7.10.4 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: <linux-media.vger.kernel.org> X-Mailing-List: linux-media@vger.kernel.org X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.10.16.193314 X-PMX-Spam: Gauge=IIIIIIII, Probability=8%, Report=' MULTIPLE_RCPTS 0.1, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1300_1399 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, CT_TEXT_PLAIN_UTF8_CAPS 0, DKIM_SIGNATURE 0, URI_ENDS_IN_HTML 0, __ANY_URI 0, __CP_MEDIA_BODY 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FRAUD_BODY_WEBMAIL 0, __FRAUD_WEBMAIL 0, __FRAUD_WEBMAIL_FROM 0, __HAS_FROM 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __HAS_X_MAILING_LIST 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MULTIPLE_RCPTS_CC_X2 0, __PHISH_SPEAR_STRUCTURE_1 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_WWW 0, __URI_NS , __YOUTUBE_RCVD 0' |
Commit Message
Frank Schaefer
Oct. 16, 2013, 7:41 p.m. UTC
Commit 622b828ab7 ("v4l2_subdev: rename tuner s_standby operation to
core s_power") replaced the tuner s_standby call in the em28xx driver with
a (s_power, 0) call which suspends all subdevices.
But it neglected to add corresponding (s_power, 1) calls to make sure that
the subdevices are powered on again when needed.
This patch fixes this issue by adding a (s_power, 1) call to
function em28xx_wake_i2c().
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
---
drivers/media/usb/em28xx/em28xx-core.c | 1 +
1 Datei geändert, 1 Zeile hinzugefügt(+)
Comments
Hi Frank Thanks for the patch On Wed, 16 Oct 2013, Frank Schäfer wrote: > Commit 622b828ab7 ("v4l2_subdev: rename tuner s_standby operation to > core s_power") replaced the tuner s_standby call in the em28xx driver with > a (s_power, 0) call which suspends all subdevices. > But it neglected to add corresponding (s_power, 1) calls to make sure that > the subdevices are powered on again when needed. > > This patch fixes this issue by adding a (s_power, 1) call to > function em28xx_wake_i2c(). > > Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> > --- > drivers/media/usb/em28xx/em28xx-core.c | 1 + > 1 Datei geändert, 1 Zeile hinzugefügt(+) > > diff --git a/drivers/media/usb/em28xx/em28xx-core.c b/drivers/media/usb/em28xx/em28xx-core.c > index fc157af..8896789 100644 > --- a/drivers/media/usb/em28xx/em28xx-core.c > +++ b/drivers/media/usb/em28xx/em28xx-core.c > @@ -1243,6 +1243,7 @@ EXPORT_SYMBOL_GPL(em28xx_init_usb_xfer); > */ > void em28xx_wake_i2c(struct em28xx *dev) > { > + v4l2_device_call_all(&dev->v4l2_dev, 0, core, s_power, 1); > v4l2_device_call_all(&dev->v4l2_dev, 0, core, reset, 0); > v4l2_device_call_all(&dev->v4l2_dev, 0, video, s_routing, > INPUT(dev->ctl_input)->vmux, 0, 0); Do I understand it right, that you're proposing this as an alternative to my power-balancing patch? It's certainly smaller and simpler, have you also tested it with the ov2640 and my clock patches to see, whether this really balances calls to .s_power() perfectly? 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am 18.10.2013 22:30, schrieb Guennadi Liakhovetski: > Hi Frank > > Thanks for the patch > > On Wed, 16 Oct 2013, Frank Schäfer wrote: > >> Commit 622b828ab7 ("v4l2_subdev: rename tuner s_standby operation to >> core s_power") replaced the tuner s_standby call in the em28xx driver with >> a (s_power, 0) call which suspends all subdevices. >> But it neglected to add corresponding (s_power, 1) calls to make sure that >> the subdevices are powered on again when needed. >> >> This patch fixes this issue by adding a (s_power, 1) call to >> function em28xx_wake_i2c(). >> >> Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> >> --- >> drivers/media/usb/em28xx/em28xx-core.c | 1 + >> 1 Datei geändert, 1 Zeile hinzugefügt(+) >> >> diff --git a/drivers/media/usb/em28xx/em28xx-core.c b/drivers/media/usb/em28xx/em28xx-core.c >> index fc157af..8896789 100644 >> --- a/drivers/media/usb/em28xx/em28xx-core.c >> +++ b/drivers/media/usb/em28xx/em28xx-core.c >> @@ -1243,6 +1243,7 @@ EXPORT_SYMBOL_GPL(em28xx_init_usb_xfer); >> */ >> void em28xx_wake_i2c(struct em28xx *dev) >> { >> + v4l2_device_call_all(&dev->v4l2_dev, 0, core, s_power, 1); >> v4l2_device_call_all(&dev->v4l2_dev, 0, core, reset, 0); >> v4l2_device_call_all(&dev->v4l2_dev, 0, video, s_routing, >> INPUT(dev->ctl_input)->vmux, 0, 0); > Do I understand it right, that you're proposing this as an alternative to > my power-balancing patch? Yes. Your patch was nevertheless useful, because it pointed out further bugs in em28xx_v4l2_open(). I've sent another RFC patch which should fix them, too. > It's certainly smaller and simpler, have you > also tested it with the ov2640 and my clock patches to see, whether this > really balances calls to .s_power() perfectly? Yes, I've tested the patch with the VAD Laplace webcam (ov2640), a Hauppauge HVR 900 and a Terratec Cinergy 200. Please note that the patch does not balance .s_power() calls perfectly, it only makes sure that the subdevices are powered on when needed. This also avoids the scary v4l2-clk warnings. Due to the various GPIO sequences, I see no chance to make s_power calls really balanced in such drivers. Regards, Frank > 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Frank On Sat, 19 Oct 2013, Frank SchÀfer wrote: > Am 18.10.2013 22:30, schrieb Guennadi Liakhovetski: > > Hi Frank > > > > Thanks for the patch > > > > On Wed, 16 Oct 2013, Frank SchÀfer wrote: > > > >> Commit 622b828ab7 ("v4l2_subdev: rename tuner s_standby operation to > >> core s_power") replaced the tuner s_standby call in the em28xx driver with > >> a (s_power, 0) call which suspends all subdevices. > >> But it neglected to add corresponding (s_power, 1) calls to make sure that > >> the subdevices are powered on again when needed. > >> > >> This patch fixes this issue by adding a (s_power, 1) call to > >> function em28xx_wake_i2c(). > >> > >> Signed-off-by: Frank SchÀfer <fschaefer.oss@googlemail.com> > >> --- > >> drivers/media/usb/em28xx/em28xx-core.c | 1 + > >> 1 Datei geÀndert, 1 Zeile hinzugefÌgt(+) > >> > >> diff --git a/drivers/media/usb/em28xx/em28xx-core.c b/drivers/media/usb/em28xx/em28xx-core.c > >> index fc157af..8896789 100644 > >> --- a/drivers/media/usb/em28xx/em28xx-core.c > >> +++ b/drivers/media/usb/em28xx/em28xx-core.c > >> @@ -1243,6 +1243,7 @@ EXPORT_SYMBOL_GPL(em28xx_init_usb_xfer); > >> */ > >> void em28xx_wake_i2c(struct em28xx *dev) > >> { > >> + v4l2_device_call_all(&dev->v4l2_dev, 0, core, s_power, 1); > >> v4l2_device_call_all(&dev->v4l2_dev, 0, core, reset, 0); > >> v4l2_device_call_all(&dev->v4l2_dev, 0, video, s_routing, > >> INPUT(dev->ctl_input)->vmux, 0, 0); > > Do I understand it right, that you're proposing this as an alternative to > > my power-balancing patch? > Yes. > Your patch was nevertheless useful, because it pointed out further bugs > in em28xx_v4l2_open(). > I've sent another RFC patch which should fix them, too. > > > It's certainly smaller and simpler, have you > > also tested it with the ov2640 and my clock patches to see, whether this > > really balances calls to .s_power() perfectly? > Yes, I've tested the patch with the VAD Laplace webcam (ov2640), a > Hauppauge HVR 900 and a Terratec Cinergy 200. > Please note that the patch does not balance .s_power() calls perfectly, > it only makes sure that the subdevices are powered on when needed. > This also avoids the scary v4l2-clk warnings. hmm, I'm not sure I quite understand - calls aren't balanced perfectly, but warnings are gone? Since warnings are gone, this means the use-count doesn't go negative. Does that mean, that now you enable the clock more often, then you disable it? Wouldn't it lock the driver module in the kernel via excessive module_get()? Or have I misunderstood something? > Due to the various GPIO sequences, I see no chance to make s_power calls > really balanced in such drivers. I think those should be fixed actually. If there are indeed GPIO operations, that switch subdevice power on and off, they should be coded as such, perhaps as regulators. And - as discussed elsewhere - actually subdevice drivers should decide when power should be supplied to them, and when not. Anyway, if your patch keeps the clock use count between 0 when unused and 1, when used, I vote for it and would suggest to apply these fixes to em28xx. Mauro, can we do this? Shall we repost the set to make it easier? 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Guennadi, Am 19.10.2013 18:32, schrieb Guennadi Liakhovetski: > Hi Frank > > On Sat, 19 Oct 2013, Frank SchÀfer wrote: > >> Am 18.10.2013 22:30, schrieb Guennadi Liakhovetski: >>> Hi Frank >>> >>> Thanks for the patch >>> >>> On Wed, 16 Oct 2013, Frank SchÀfer wrote: >>> >>>> Commit 622b828ab7 ("v4l2_subdev: rename tuner s_standby operation to >>>> core s_power") replaced the tuner s_standby call in the em28xx driver with >>>> a (s_power, 0) call which suspends all subdevices. >>>> But it neglected to add corresponding (s_power, 1) calls to make sure that >>>> the subdevices are powered on again when needed. >>>> >>>> This patch fixes this issue by adding a (s_power, 1) call to >>>> function em28xx_wake_i2c(). >>>> >>>> Signed-off-by: Frank SchÀfer <fschaefer.oss@googlemail.com> >>>> --- >>>> drivers/media/usb/em28xx/em28xx-core.c | 1 + >>>> 1 Datei geÀndert, 1 Zeile hinzugefÌgt(+) >>>> >>>> diff --git a/drivers/media/usb/em28xx/em28xx-core.c b/drivers/media/usb/em28xx/em28xx-core.c >>>> index fc157af..8896789 100644 >>>> --- a/drivers/media/usb/em28xx/em28xx-core.c >>>> +++ b/drivers/media/usb/em28xx/em28xx-core.c >>>> @@ -1243,6 +1243,7 @@ EXPORT_SYMBOL_GPL(em28xx_init_usb_xfer); >>>> */ >>>> void em28xx_wake_i2c(struct em28xx *dev) >>>> { >>>> + v4l2_device_call_all(&dev->v4l2_dev, 0, core, s_power, 1); >>>> v4l2_device_call_all(&dev->v4l2_dev, 0, core, reset, 0); >>>> v4l2_device_call_all(&dev->v4l2_dev, 0, video, s_routing, >>>> INPUT(dev->ctl_input)->vmux, 0, 0); >>> Do I understand it right, that you're proposing this as an alternative to >>> my power-balancing patch? >> Yes. >> Your patch was nevertheless useful, because it pointed out further bugs >> in em28xx_v4l2_open(). >> I've sent another RFC patch which should fix them, too. >> >>> It's certainly smaller and simpler, have you >>> also tested it with the ov2640 and my clock patches to see, whether this >>> really balances calls to .s_power() perfectly? >> Yes, I've tested the patch with the VAD Laplace webcam (ov2640), a >> Hauppauge HVR 900 and a Terratec Cinergy 200. >> Please note that the patch does not balance .s_power() calls perfectly, >> it only makes sure that the subdevices are powered on when needed. >> This also avoids the scary v4l2-clk warnings. > hmm, I'm not sure I quite understand - calls aren't balanced perfectly, > but warnings are gone? Since warnings are gone, this means the use-count > doesn't go negative. Correct. > Does that mean, that now you enable the clock more > often, then you disable it? (s_power, 1) is called more often than (s_power, 0). > Wouldn't it lock the driver module in the > kernel via excessive module_get()? Or have I misunderstood something? I don't know. Wouldn't this be a bug ? >> Due to the various GPIO sequences, I see no chance to make s_power calls >> really balanced in such drivers. > I think those should be fixed actually. If there are indeed GPIO > operations, that switch subdevice power on and off, they should be coded > as such, perhaps as regulators. Sure, that's how it _should_ be. Care to fix the em28xx driver ? Do you have all the 90+ devices ? Do you have time enough time to figure out/investigate their GPIO port assignments and test them all ? The em28xx driver is very old (~10 years ?) and other drivers are even older. Nobody cared about the GPIO details these days and there were also no appropriate APIs for things like power control. I agree that it would be nice to get things right, but I see no realistic chance to achieve that. > And - as discussed elsewhere - actually > subdevice drivers should decide when power should be supplied to them, and > when not. I still disagree in this point. IMHO, this decision should be left to the master device that controls the subdevice. > Anyway, if your patch keeps the clock use count between 0 when unused and > 1, when used, I vote for it and would suggest to apply these fixes to > em28xx. Apparently soc_camera calls v4l2_clk_enable() each time (s_power, 1) is called. Because s_power can't be balanced, v4l2_clk_enable()/disable() calls aren't balanced, too. :/ This issue needs to be addressed indeed. Regards, Frank > Mauro, can we do this? Shall we repost the set to make it easier? > > 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Frank, On Sun, 20 Oct 2013, Frank Schäfer wrote: > Hi Guennadi, > > Am 19.10.2013 18:32, schrieb Guennadi Liakhovetski: > > Hi Frank > > > > On Sat, 19 Oct 2013, Frank SchÀfer wrote: > > > >> Am 18.10.2013 22:30, schrieb Guennadi Liakhovetski: > >>> Hi Frank > >>> > >>> Thanks for the patch > >>> > >>> On Wed, 16 Oct 2013, Frank SchÀfer wrote: > >>> > >>>> Commit 622b828ab7 ("v4l2_subdev: rename tuner s_standby operation to > >>>> core s_power") replaced the tuner s_standby call in the em28xx driver with > >>>> a (s_power, 0) call which suspends all subdevices. > >>>> But it neglected to add corresponding (s_power, 1) calls to make sure that > >>>> the subdevices are powered on again when needed. > >>>> > >>>> This patch fixes this issue by adding a (s_power, 1) call to > >>>> function em28xx_wake_i2c(). > >>>> > >>>> Signed-off-by: Frank SchÀfer <fschaefer.oss@googlemail.com> > >>>> --- > >>>> drivers/media/usb/em28xx/em28xx-core.c | 1 + > >>>> 1 Datei geÀndert, 1 Zeile hinzugefÃŒgt(+) > >>>> > >>>> diff --git a/drivers/media/usb/em28xx/em28xx-core.c b/drivers/media/usb/em28xx/em28xx-core.c > >>>> index fc157af..8896789 100644 > >>>> --- a/drivers/media/usb/em28xx/em28xx-core.c > >>>> +++ b/drivers/media/usb/em28xx/em28xx-core.c > >>>> @@ -1243,6 +1243,7 @@ EXPORT_SYMBOL_GPL(em28xx_init_usb_xfer); > >>>> */ > >>>> void em28xx_wake_i2c(struct em28xx *dev) > >>>> { > >>>> + v4l2_device_call_all(&dev->v4l2_dev, 0, core, s_power, 1); > >>>> v4l2_device_call_all(&dev->v4l2_dev, 0, core, reset, 0); > >>>> v4l2_device_call_all(&dev->v4l2_dev, 0, video, s_routing, > >>>> INPUT(dev->ctl_input)->vmux, 0, 0); > >>> Do I understand it right, that you're proposing this as an alternative to > >>> my power-balancing patch? > >> Yes. > >> Your patch was nevertheless useful, because it pointed out further bugs > >> in em28xx_v4l2_open(). > >> I've sent another RFC patch which should fix them, too. > >> > >>> It's certainly smaller and simpler, have you > >>> also tested it with the ov2640 and my clock patches to see, whether this > >>> really balances calls to .s_power() perfectly? > >> Yes, I've tested the patch with the VAD Laplace webcam (ov2640), a > >> Hauppauge HVR 900 and a Terratec Cinergy 200. > >> Please note that the patch does not balance .s_power() calls perfectly, > >> it only makes sure that the subdevices are powered on when needed. > >> This also avoids the scary v4l2-clk warnings. > > hmm, I'm not sure I quite understand - calls aren't balanced perfectly, > > but warnings are gone? Since warnings are gone, this means the use-count > > doesn't go negative. > Correct. > > > Does that mean, that now you enable the clock more > > often, then you disable it? > (s_power, 1) is called more often than (s_power, 0). This is not good. > > Wouldn't it lock the driver module in the > > kernel via excessive module_get()? Or have I misunderstood something? > I don't know. Wouldn't this be a bug ? Indeed, so, I personally don't think we can merge your patch together with my other patches as they stand now. We should either fix your patch to strictly balance calls to .s_power() or make soc_camera_power_on() and soc_camera_power_off() balance calls to clk_enable() / clk_disable() internally, which might indeed be a better option in the present situation. I'll try to post patches tomorrow. Thanks Guennadi > >> Due to the various GPIO sequences, I see no chance to make s_power calls > >> really balanced in such drivers. > > I think those should be fixed actually. If there are indeed GPIO > > operations, that switch subdevice power on and off, they should be coded > > as such, perhaps as regulators. > Sure, that's how it _should_ be. > Care to fix the em28xx driver ? Do you have all the 90+ devices ? Do you > have time enough time to figure out/investigate their GPIO port > assignments and test them all ? > > The em28xx driver is very old (~10 years ?) and other drivers are even > older. > Nobody cared about the GPIO details these days and there were also no > appropriate APIs for things like power control. > I agree that it would be nice to get things right, but I see no > realistic chance to achieve that. > > > And - as discussed elsewhere - actually > > subdevice drivers should decide when power should be supplied to them, and > > when not. > I still disagree in this point. > IMHO, this decision should be left to the master device that controls > the subdevice. > > > Anyway, if your patch keeps the clock use count between 0 when unused and > > 1, when used, I vote for it and would suggest to apply these fixes to > > em28xx. > Apparently soc_camera calls v4l2_clk_enable() each time (s_power, 1) is > called. > Because s_power can't be balanced, v4l2_clk_enable()/disable() calls > aren't balanced, too. :/ > This issue needs to be addressed indeed. > > Regards, > Frank > > > Mauro, can we do this? Shall we repost the set to make it easier? > > > > Thanks > > Guennadi > > --- > > Guennadi Liakhovetski, Ph.D. > > Freelance Open-Source Software Developer > > http://www.open-technology.de/ > --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/media/usb/em28xx/em28xx-core.c b/drivers/media/usb/em28xx/em28xx-core.c index fc157af..8896789 100644 --- a/drivers/media/usb/em28xx/em28xx-core.c +++ b/drivers/media/usb/em28xx/em28xx-core.c @@ -1243,6 +1243,7 @@ EXPORT_SYMBOL_GPL(em28xx_init_usb_xfer); */ void em28xx_wake_i2c(struct em28xx *dev) { + v4l2_device_call_all(&dev->v4l2_dev, 0, core, s_power, 1); v4l2_device_call_all(&dev->v4l2_dev, 0, core, reset, 0); v4l2_device_call_all(&dev->v4l2_dev, 0, video, s_routing, INPUT(dev->ctl_input)->vmux, 0, 0);