On Thu, Aug 28, 2014 at 3:47 PM, Daniel Mack <daniel@xxxxxxxxxx> wrote: > On 08/28/2014 12:10 PM, Jassi Brar wrote: >> On Thu, Aug 28, 2014 at 3:33 PM, Daniel Mack <daniel@xxxxxxxxxx> wrote: > >>> It's still superior to a number of unnecessary calculations done every >>> millisecond which will come up with the same result every time. So I >>> clearly favor that approach. Three more ints in a struct don't hurt >>> really for something that's usually not instantiated more than once per >>> system. >>> >>> Anyway, I'll leave it to Felipe whether to merge v5 or v6 :) >>> >> Please wait, let me cook up a patch that uses (a) Alan's algo, (b) >> cause lesser churn and (c) is even 'faster'. > > Alright. > > Please note, however, that you can't do the divison 'uac2->p_residue / > uac2->p_interval' in a pre-calucated value, as that won't cover cases > with a per-packet residual value that isn't a multiple of the frame > size. Hence, the residue counter has to go in bytes, not frames, and for > that reason, I left that division in the per-packet loop. > > Felipe, could you already merge patch 1-5 of the last series (v6)? > err.. 1-4 of v6 :) right? Yes please, Felipe, we have no contention on those nice patches. Thanks Jassi -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
