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 ca
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
--- linux-3.0/drivers/media/video/em28xx/em28xx-cards.c.orig 2011-0
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
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. Tho
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) 4.6
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
19:21:34
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
> >
Em 20-08-2011 07:40, Chris Rankin escreveu:
> --- On Sat, 20/8/11, Mauro Carvalho Chehab 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
>>
--- On Sat, 20/8/11, Mauro Carvalho Chehab 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 when someone plu
Em 20-08-2011 06:46, Chris Rankin escreveu:
> --- On Sat, 20/8/11, Mauro Carvalho Chehab 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?
No, it
--- On Sat, 20/8/11, Mauro Carvalho Chehab 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 list: send the l
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
#
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 tha
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
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: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
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 mut
*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 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 wr
There's no reason to still be holding the device list mutex for either of these
printk statements.
Signed-off-by: Chris Rankin
--- linux-3.0/drivers/media/video/em28xx/em28xx-core.c.orig 2011-08-18 23:05:50.0 +0100
+++ linux-3.0/drivers/media/video/em28xx/em28xx-core.c 2011-08-18 23:07
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
--- linux-3.0/drivers/media/video/em28xx/em28xx-cards.c.
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 requiremen
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
--- linux-3.0/drivers/media/video/em28xx/em28xx-cards.c
Release the dev->alt_max_pkt_size buffer in all cases.
Signed-off-by: Chris Rankin
--- 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
@@ -2202,6 +2202,7 @@
snprintf()'s size parameter includes space for the terminating '\0' character.
Signed-off-by: Chris Rankin
--- 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 22:03:05.0 +0100
26 matches
Mail list logo
