On Fri, Oct 06, 2006 at 11:39:16PM -0400, Christopher Monty Montgomery wrote: > On 10/6/06, David Brownell <[EMAIL PROTECTED]> wrote: > > >> My other points still stand. This patch is necessitated by the other > >> patches. > > > >Did one of them cause EL2NSYNC to get reported differently then? > > No, I mean that standard usage patterns will reliably cause an > EL2NSYNC when my new scheduler patches are applied. Having the new > scheduler patches, but not the usbaudio patch, will mean that usbaudio > stops working. This is all due to my changes. > > EL2NSYNC happened before, but exceedingly rarely. With my patches, > eg, apps using OSS will hit it every time. > > >You seem to have missed a key point of splitting a monster patch > >into a sequence of independent patches ... the independence! > > I would assert the key point is being able to see each change in > isolation clearly.
I concur. > >That is, in any series of patches 1..N it's a goal that later > >patches be independent of earlier ones ... in the sense that > >dropping the later ones not break anything, since the series > >as a whole is _functionally_ incremental. Not only should the > >system build with just the first N patches, but it should WORK > >that way too. (And depending on the patches, a given patch > >might not actually depend on preceding patches. It's good to > >factor patches to minimize dependencies, when you can.) > > That argues against any attempt to split up this patch given that the > chages are, by their nature, mostly interdependent. But it was an > asserted requirement and I complied. And I think you met it very well. Each step along the way builds properly, which, for a set this big is a very tough thing to do. Monty, you've done very nice job here. This feature is one that we have been needing for a while now, thanks for taking the time to implement it. > >I don't think I disagreed with (b), although I think (a) must > >then be obviously wrong ... otherwise it'd be impossible for > >(b) to be true! :) > > I was conflating xrun with loss of sync as several others noted. We > couldn't detect loss of sync, and in the case of xrun, we release the > bandwidth allocation (which is making the error worse). > > >However my point was that this is the wrong fix. Since it's > >already broken, and the issue seems unrelated to the patches > >you've posted, it's reasonable to hold out for the right fix. > > It's clear the Big Patchset is also going to require changes. And > that usbaudio does indeed need a fix (more than one in fact). > However, having #15 is better than not having #15 if #1-14 are > applied. > > >The patch you posted may make an OK workaround for certain > >configurations though. > > Well, it sounds like EL2NSYNC has to go away as it wasn't the proper > established channel for reporting the missed slots, and higher level > drivers aren't expecting it because it wasn't documented (if, in fact, > it ever did what I though it did, which apparently it didn't) Ok, then what is the proper channel for reporting the missed slots? Did I miss something here? thanks, greg k-h ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
