From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Hogan Subject: Re: mmc_test Correct xfer_size at write Date: Wed, 29 Jun 2011 09:06:22 +0100 Message-ID: <4E0ADCFE.90102@imgtec.com> References: <4E09AEE5.4050505@imgtec.com> <20110628185028.6af91b87@mjolnir.ossman.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: Received: from multi.imgtec.com ([194.200.65.239]:7192 "EHLO multi.imgtec.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751463Ab1F2IGn (ORCPT ); Wed, 29 Jun 2011 04:06:43 -0400 In-Reply-To: <20110628185028.6af91b87@mjolnir.ossman.eu> Sender: linux-mmc-owner@vger.kernel.org List-Id: linux-mmc@vger.kernel.org To: Pierre Ossman Cc: linux-mmc On 06/28/2011 05:50 PM, Pierre Ossman wrote: > On Tue, 28 Jun 2011 11:37:25 +0100 > James Hogan wrote: > >> Hi, >> >> I'm trying to figure out why the broken write transfer tests in mmc_test >> require the result to be -ETIMEDOUT, so that I can make dw_mmc pass >> these tests. Perhaps somebody could explain. >> >> I can understand for reads, that the controller is waiting for the start >> bit on the data lines and so it can timeout after a while if it doesn't >> see any. However for writes (as far as I can glean from the physical >> layer spec and a logic analyser) the data response token which is >> normally sent by the card in response to a write transfer is clocked out >> immediately after the data so is either there or it isn't. >> >> Have I misunderstood it or is -ETIMEDOUT just the error that is required >> by convention when the data response token is not detected? >> > > It's more or less by convention. ETIMEDOUT is the closest thing we have > to "we expected a response from the card but got bupkis". You can find > some informal definitions here: > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=include/linux/mmc/core.h;h=b6718e549a510780e0f8c9a3be17e64753d6c2f5;hb=HEAD#l81 > > Rgds Thanks for the info Pierre James