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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

Regards
Eddi


On Mon, Dec 5, 2011 at 9:01 PM, Devin Heitmueller
<dheitmueller@xxxxxxxxxxxxxx> wrote:
> On Mon, Dec 5, 2011 at 1:46 PM, Devin Heitmueller
> <dheitmueller@xxxxxxxxxxxxxx> wrote:
>> On Mon, Dec 5, 2011 at 1:35 PM, Mauro Carvalho Chehab
>> <mchehab@xxxxxxxxxx> wrote:
>>>> What's up with this change?  Is this a bugfix for some race condition?
>>>>  Why is it jammed into a patch for some particular product?
>>>>
>>>> It seems like a change such as this could significantly change the
>>>> timing of tuner initialization if you have multiple xc5000 based
>>>> products that might have a slow i2c bus.  Was that intentional?
>>>>
>>>> This patch should be NACK'd and resubmitted as it's own bugfix where
>>>> it's implications can be fully understood in the context of all the
>>>> other products that use xc5000.
>>>
>>>
>>> It is too late for nacking the patch, as there are several other patches
>>> were already applied on the top of it, and we don't rebase the
>>> linux-media.git tree.
>>>
>>> Assuming that this is due to some bug that Eddi picked during xc5000
>>> init, what it can be done now is to write a patch that would replace
>>> this xc5000-global mutex lock into a some other per-device locking
>>> schema.
>>
>> At this point we have zero idea why it's there *at all*.  Eddi, can
>> you comment on what prompted this change?
>>
>> This patch should not have been accepted in the first place.  It's an
>> undocumented change on a different driver than is advertised in the
>> subject line.  Did you review the patch prior to merging?
>>
>> This change can result in a performance regression for all other
>> devices using xc5000, and it's not yet clear why it's there in the
>> first place.  If its use cannot be explained then it should be rolled
>> back.  If this breaks 930c, then the whole device support series
>> should be rolled back until somebody can figure out what is going on.
>>
>> It's crap like this that is the reason that every other week I get
>> complaints from some user that one of the drivers I wrote support for
>> worked fine for months/years until they upgraded to the latest kernel.
>
> Speaking of which, Mark Lord just tried out this change (he has an
> 800i and 950q - both xc5000 based), and now his DVB stack fails to
> load.  And yes, he already has the fix to the mutex_unlock()
> regression which Dan Carpenter found six days ago and which this patch
> introduced.
>
> Devin
>
> --
> Devin J. Heitmueller - Kernel Labs
> http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux