DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=f91OQzIXyvlv9HGSwLs40wQoJWdMRazz9uagPl+ofkR0oluU+IW7l7TqiZj4uUN9txbQpXo7FBD0LeXrv90jHxlt6qVDPfyE/fDlnOyslY1OnkWjANZmCyAco3iUyxj6e6hLG4SF+fGl/1H6CZIJztCcFw4yEMR6iISxMI7zAIw=  ;
Message-ID: <20060907030049.35159.qmail@web36713.mail.mud.yahoo.com>
Date: Wed, 6 Sep 2006 20:00:49 -0700 (PDT)
From: Alex Dubov <oakad@yahoo.com>
Subject: Re: Support for TI FlashMedia (pci id 104c:8033, 104c:803b) flash card readers
To: Pierre Ossman <drzeus-list@drzeus.cx>
Cc: linux-kernel@vger.kernel.org
In-Reply-To: <44FE5668.4090000@drzeus.cx>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1088
Lines: 23


As a temporal work-around to the timeout problem I've put the following in:
1. All data timeout values are multiplied by a fudge factor of 10 (this is still lower latency
than waiting for a software fall-back).
2. I've added a module option to disable hardware data timeout at all. This is how TI does it too
- command timeout is set to 64 clocks are data timeouts (if any) are captured by the slow software
handler. Card removal is signalled by its own interrupt, so the wait for data in this case will be
aborted anyway.
I haven't checked out your patch yet.

For a written blocks I'm now reporting the BUSY de-assert count rather than block counter value. I
hope this is a good idea.


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/