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 <dheitmuel...@kernellabs.com> wrote: > On Mon, Dec 5, 2011 at 1:46 PM, Devin Heitmueller > <dheitmuel...@kernellabs.com> wrote: >> On Mon, Dec 5, 2011 at 1:35 PM, Mauro Carvalho Chehab >> <mche...@redhat.com> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
