Re: [PATCH 5/8] [media] em28xx: initial support for HAUPPAUGE HVR-930C again

[Mauro Carvalho Chehab <mchehab@redhat.com>]

On 06-12-2011 10:51, Mark Lord wrote:
> On 11-12-05 06:47 PM, Devin Heitmueller wrote:
>> On Mon, Dec 5, 2011 at 6:32 PM, Eddi De Pieri<eddi@depieri.net>  wrote:
>>> Sorry,  I think I applied follow patch on my tree while I developed
>>> the driver trying to fix tuner initialization.
>>>
>>> http://patchwork.linuxtv.org/patch/6617/
>>>
>>> I forgot to remove from my tree after I see that don't solve anything.
>>
>> Ok, great.  At least that explains why it's there (since I couldn't
>> figure out how on Earth the patch made sense otherwise).
>>
>> Eddi, could you please submit a patch removing the offending code?
>
>
> That's good.
>
> But there definitely still is a race between modules in there somewhere.
> The HVR-950Q tuners use several:  xc5000, au8522, au0828, ..
> and unless au0828 is loaded *last*, with a delay before/after,
> the dongles don't always work.  Preloading all of the modules
> before allowing hardware detection seems to help.
>
> Even just changing from a mechanical hard drive to a very fast SSD
> is enough to change the behaviour from not-working to working
> (and sometimes the other way around).
>
> I tried to track this down a couple of years ago,
> and found cross-module calls failing because the
> target functions hadn't been loaded yet.
> But my lack of notes from 2-3 years ago isn't helpful here.
>
> Here's a similar report from 2 years ago, as valid today as it was then:
>
>    http://www.mythtv.org/pipermail/mythtv-users/2010-January/279912.html

The driver who binds everything is the bridge driver. In your case, it is
the au0828 driver.

What you're experiencing seems to be some race issue inside it, and not at xc5000.

On a quick look on it, I'm noticing that there's no lock at au0828_usb_probe().

Also, it uses a separate lock for analog and for digital:

	mutex_init(&dev->mutex);
	mutex_init(&dev->dvb.lock);

Probably, the right thing to do would be to use just one lock for both rising
it at usb_probe, lowering it just before return 0. This will avoid any open
operations while the device is not fully initialized. Btw, newer udev's open
the analog part of the driver just after V4L register, in order to get the
device capabilities. This is known to cause race conditions, if the locking
schema is not working properly.

Regards,
Mauro.