From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mx.fr.smartjog.net ([95.81.144.3]:54177 "EHLO mx.fr.smartjog.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751639Ab2H3PVc (ORCPT ); Thu, 30 Aug 2012 11:21:32 -0400 Message-ID: <503F84F5.9010304@smartjog.com> Date: Thu, 30 Aug 2012 17:21:25 +0200 From: =?UTF-8?B?UsOpbWkgQ2FyZG9uYQ==?= MIME-Version: 1.0 To: Antti Palosaari CC: linux-media@vger.kernel.org Subject: Re: [PATCH 2/2] [media] ds3000: properly report firmware loading issues References: <1346319391-19015-1-git-send-email-remi.cardona@smartjog.com> <1346319391-19015-3-git-send-email-remi.cardona@smartjog.com> <503F6D18.2060804@iki.fi> In-Reply-To: <503F6D18.2060804@iki.fi> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-media-owner@vger.kernel.org List-ID: 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