Hi Antti, On 08/30/2012 03:39 PM, Antti Palosaari wrote: > As I understand firmware downloading failure is coming from the fact > that register read fails => fails to detect if firmware is already > running or not. Well we actually see 2 cases: - the register read failure (when ds3000_readreg() returns negative values). This case is fairly rare, and no changes we've done to the driver allowed us to make those cards work. - the register read returning 0. Looking at the current code, it looks like the 0xb2 register is supposed to mean that a firmware is loaded. This case is fairly common: we've had many cards randomly saying that a firmware was loaded when none had been. Often, a simple reboot will do the trick. But sometimes, forcing the firmware upload (ie, bypassing the 0xb2 register check) allows the stubborn cards to function properly. > Original behavior to expect firmware is loaded and running when register > read fails is very stupid and your fix seems much better. Well, this patch should not really change the behavior. It just propagates register read errors to ds3000_initfe(). It'll just fail earlier. > So first priority should be try fix that issue with register read. Is it > coming from the USB stack (eg. error 110 timeout) or some other error > coming from the fact chip answers wrong? The cards we're using are PCIe (and not the ones with an embedded USB controller). > Do you see other register I/O failing too? I'll see if I can get you an answer for that, since the cards are shipped with the appliance we send to our customers. Remote debugging is somewhat tricky. > Does adding few usec sleep help? I'm not quite sure where to add those sleeps. In the register reading/writing functions? 10us? 100us? Many thanks Rémi -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
