On Tue, 10 Feb 2015, Michael Tessier wrote: > > > Okay; I did my homeworks. We've loaded kernel V3.16 (Oct 14th, 2015) > > > on an i.MX51 plattform and the problem is still there. Unless an > > > important change occured in V3.19, it appears that the latest kernel > > > is not the solution for us. So we're still not able to use 4 codecs on > > > our i.MX plattform. > > > > > > So just to make things clearer: > > > - We have customers waiting for a solution with that hardware (this > > > hardware is already delivred AND used); > > > - We have important comittments and severe penalties ($$$) if we're > > > not able to deliver on time (due for March 15th); > > > - We've already looked at a hardware solution, which corresponds to > > > replace current units ($$$$$), so that is not really an option for us; > > > > > > So as a last resort, I'm wondering, where is the USB expert who could > > > help us solving our problem? Any suggestions? > > > > That would be me. > > Great. What do you need to make it a priority? Let's put it this way: Fixing bugs in the ehci-hcd driver already is a priority for me. But it takes second place to other priorities, such as my day job. (And incidentally, finding and fixing bugs in kernels as old as 2.6.31 is _not_ a priority, since so many have already been found and fixed. That is one important reason for my suggestion that you do the debugging with the most recent kernel version you can.) > > > If we are to get into debugging the USB driver, we would do it with > > > the current kernel used (V2.6.31). What are the better tools to get > > > into that? I guess a USB analyzer (hardware) would be the smart thing? > > > Any brand name to suggest? > > > > It really would be better to start by debugging the most recent kernel possible. Once the problem has been solved there, it should be fairly straightforward to port it back. > > How much time do you think you'd spend solving that kind of issue? > Few days? Few weeks, or few months? No idea. In the past, such things have taken a few days to a few weeks, depending on lots of factors -- when they are solvable at all. > Could you commit on a certain > number of hours? (We are trying to evaluate a possible date where we > could start delivering products) No, I can't commit to anything specific. > When you say "straightforward", again do you have an idea of the > amount of time to do such work? Again, it all depends. For example, it might turn out that the hardware you are using contains a bug of a sort I have seen in the past. In that case, programming a workaround wouldn't take more than a few hours, once I knew what was going on. Alan Stern -- 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
