Pandita, Vikram wrote: > On Mon, Jul 18, 2011 at 11:22 PM, Gadiyar, Anand <gadiyar@xxxxxx> wrote: > >> From: Vikram Pandita <vikram.pandita@xxxxxx> > >> > >> This patch enables the DMA mode1 RX support. > >> This feature is enabled based on the short_not_ok flag passed from > >> gadget drivers. > >> > >> This will result in a thruput performance gain of around > >> 40% for USB mass-storage/mtp use cases. > >> > >> Based on Original work by > >> Anand Gadiyar <gadiyar@xxxxxx> on 2.6.35 kernel > >> > >> Change-Id: I9b3a7cae73b63e86128d2caf4cdd67ab77556e75 > >> Signed-off-by: Moiz Sonasath <m-sonasath@xxxxxx> > >> Signed-off-by: Vikram Pandita <vikram.pandita@xxxxxx> > > > > I think the change-id should not be included in upstream > > submissions - it may not be useful to someone looking at > > the changelog. So you probably should drop it. > > yes will drop that. This comes from gerrit commit hook that does not > have a meaning for upstream. > > > > > Could you please retain my authorship and sign off from the > > original patch, since I did pretty much all the original work > > on writing this patch > > That is given and clearly mentioned in the commit message. > I will change the authorship with no issues, but would have been nice > if you could have taken this upstream. Yes, I ought to have followed up more. But this was at a time when we were promised a competing implementation from Nokia would be merged that would get mode1 working for all use cases. A patch series was posted to the mailing lists around Dec 2009 with promises off-list to repost with comments addressed - that has never happened so far. But you can't just change authorship when the entire functional code is the same. (It doesn't matter much to me - I'm not as active on MUSB as I used to be; it's just the principle of the thing). > We have been carrying this optimisation around in product kernels for > a long time now and we keep redoing on each migration, > with the downside of sometimes loosing the authorship. > > > (and if I remember correctly several > > attempts to get this merged upstream)? I don't see any > > functional changes from my original patch. > > Wonder what were the reasons for not getting accepted? > Can you re-ignite the discussion why it cannot be taken in then? You've already re-ignited this discussion. I haven't tested the patch with the current kernel (and will do so soon), but if it does still work and there are no objections, it ought to be merged. - Anand -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
