snprintf()'s size parameter includes space for the terminating '\0' character.
Signed-off-by: Chris Rankin ranki...@yahoo.com
--- linux-3.0/drivers/media/video/em28xx/em28xx-cards.c.orig 2011-08-17 08:52:19.0 +0100
+++ linux-3.0/drivers/media/video/em28xx/em28xx-cards.c 2011-08-18
Release the dev-alt_max_pkt_size buffer in all cases.
Signed-off-by: Chris Rankin ranki...@yahoo.com
--- linux-3.0/drivers/media/video/em28xx/em28xx-video.c.orig 2011-08-18 17:20:10.0 +0100
+++ linux-3.0/drivers/media/video/em28xx/em28xx-video.c 2011-08-18 17:20:33.0 +0100
@@
Use atomic bit operations for the em28xx_devused mask, to prevent an unlikely
race condition should two adapters be plugged in simultaneously. The operations
also clearer than explicit bit manipulation anyway.
Signed-off-by: Chris Rankin ranki...@yahoo.com
---
Hi Mauro,
On 08/17/2011 08:13 AM, Mauro Carvalho Chehab wrote:
It seems that there are too many miss understandings or maybe we're just
talking the same thing on different ways.
So, instead of answering again, let's re-start this discussion on a
different way.
One of the requirements
This patch ensures that the em28xx_init_dev() function cleans up after itself,
in the event that it fails. This isimportant because the struct em28xx will be
deallocated if em28xx_init_dev() returns an error.
Signed-off-by: Chris Rankin ranki...@yahoo.com
---
There's no reason to still be holding the device list mutex for either of these
printk statements.
Signed-off-by: Chris Rankin ranki...@yahoo.com
--- linux-3.0/drivers/media/video/em28xx/em28xx-core.c.orig 2011-08-18 23:05:50.0 +0100
+++
The DVB framework will try to power-down an adapter that no-one is using any
more, but this assumes that the adapter is still connected to the machine.
That's not always true for a USB adapter, so disable the sleep operations when
the adapter has been physically unplugged.
This prevents I2C
*Sigh* I overlooked two patches in the original numbering...
This patch closes the race on the device and extension lists at USB disconnect
time. Previously, the device was removed from the device list during
em28xx_release_resources(), and then passed to the em28xx_close_extension()
function
The final patch removes the unplug/replug deadlock by not holding the device
mutex during dvb_init(). However, this mutex has already been locked during
device initialisation by em28xx_usb_probe() and is not released again until all
extensions have been initialised successfully.
The device
Em 20-08-2011 04:27, Sylwester Nawrocki escreveu:
Hi Mauro,
On 08/17/2011 08:13 AM, Mauro Carvalho Chehab wrote:
It seems that there are too many miss understandings or maybe we're just
talking the same thing on different ways.
So, instead of answering again, let's re-start this discussion
Em 20-08-2011 04:37, Chris Rankin escreveu:
+
+ if (dev-state DEV_DISCONNECTED) {
+ /* We cannot tell the device to sleep
+ * once it has been unplugged. */
+ prevent_sleep(dvb-fe[0]-ops);
+
Em 20-08-2011 04:46, Chris Rankin escreveu:
The final patch removes the unplug/replug deadlock by not holding the device
mutex during dvb_init(). However, this mutex has already been locked during
device initialisation by em28xx_usb_probe() and is not released again until
all extensions
Hi Chris,
On 08/20/2011 01:42 PM, Chris Rankin wrote:
*Sigh* I overlooked two patches in the original numbering...
How about using git format-patch and git send-email ?
http://www.kernel.org/pub/software/scm/git/docs/git-send-email.html
It's easier to review when patches are inlined rather
Since the cessation of analog TV in my area, 5 of the 6 DTT multiplexes
have had their frequency changed.
You will find attached the updated file for the DVB-T transmitter of
Bourges in France.
I tested it successfully with the software Me TV Thank you kindly update.
Sincerely,
Superpat
#
Since the cessation of analog TV in my area, 5 of the 6 DTT multiplexes
have had their frequency changed.
You will find attached the updated file for the DVB-T transmitter of
Bourges in France.
I tested it successfully with the software Me TV Thank you kindly update.
Sincerely,
Superpat
#
--- On Sat, 20/8/11, Mauro Carvalho Chehab mche...@redhat.com wrot
This will cause an OOPS if dvb-fe[n] == NULL.
OK, that's trivially fixable. I'll send you an updated patch. Is it safe to
assume that dvb-fe[0] at least will always be non-NULL?
Cheers,
Chris
--
To unsubscribe from this
Em 20-08-2011 06:46, Chris Rankin escreveu:
--- On Sat, 20/8/11, Mauro Carvalho Chehab mche...@redhat.com wrot
This will cause an OOPS if dvb-fe[n] == NULL.
OK, that's trivially fixable. I'll send you an updated patch. Is it safe to
assume that dvb-fe[0] at least will always be non-NULL?
--- On Sat, 20/8/11, Mauro Carvalho Chehab mche...@redhat.com wrote:
No. The extension load can happen after the usb probe
phase. In practice, the only case where the extension init will happen
together with the usb probe phase is when the em28xx modules are
compiled builtin
It also happens
Em 20-08-2011 07:40, Chris Rankin escreveu:
--- On Sat, 20/8/11, Mauro Carvalho Chehab mche...@redhat.com wrote:
No. The extension load can happen after the usb probe
phase. In practice, the only case where the extension init will happen
together with the usb probe phase is when the em28xx
On Wed, 17 Aug 2011, Sakari Ailus wrote:
On Thu, Jul 28, 2011 at 07:04:11PM +0200, Sylwester Nawrocki wrote:
Hello,
Hi Sylwester,
Trying to capture images in JPEG format with regular image sensor -
mipi-csi receiver - host interface H/W configuration I've found there
is no standard
Here's the updated patch that checks whether the frontend exists before
disabling the sleep operations.
Cheers,
Chris
--- linux-3.0/drivers/media/common/tuners/tda18271-fe.c.orig2011-08-20
18:53:48.0 +0100
+++ linux-3.0/drivers/media/common/tuners/tda18271-fe.c 2011-08-20
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:Sat Aug 20 19:00:37 CEST 2011
git hash:9bed77ee2fb46b74782d0d9d14b92e9d07f3df6e
gcc version: i686-linux-gcc (GCC)
Why this flag is defined?
I don't see how interface driver can know CAM is ready (after plug or
reset) unless it reads that info from CAM itself. Thus, I think correct
behaviour should be move that detection functionality to the EN50221 CA
core.
Looking from existing drivers can confirm that.
On 08/17/2011 07:43 PM, Guennadi Liakhovetski wrote:
On Wed, 17 Aug 2011, Sakari Ailus wrote:
On Thu, Jul 28, 2011 at 07:04:11PM +0200, Sylwester Nawrocki wrote:
...
In order to let the host drivers query or configure subdevs with required
frame buffer size one of the following changes could
Here's the new patch for the deadlock problem, which releases the device mutex
before calling em28xx_init_extension() and then reacquires it afterwards. The
locking in dvb_init() is now left alone.
Signed-off-by: Chris Rankin ranki...@yahoo.com
---
I have a problem that may be related to the issues on this thread and
it's driving me nuts.
I have two dual tuner Afatech based cards, they are both Leadtek
2000DS cards, one made by Leadtek and the other branded as KWorld but
they are otherwise identical in spite of different VID:PID.
On each
26 matches
Mail list logo
