On Tue, 10 Feb 2015, Michael Tessier wrote:

quoted

quoted

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.)

quoted

quoted

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