From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Ball Subject: Re: SET_BLOCK_COUNT-bounded multiblock transfers Date: Thu, 14 Apr 2011 19:18:54 -0400 Message-ID: References: <1302741523-22276-1-git-send-email-andreiw@motorola.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from void.printf.net ([89.145.121.20]:41762 "EHLO void.printf.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754472Ab1DNXOX (ORCPT ); Thu, 14 Apr 2011 19:14:23 -0400 In-Reply-To: (Andrei Warkentin's message of "Thu, 14 Apr 2011 17:58:45 -0500") Sender: linux-mmc-owner@vger.kernel.org List-Id: linux-mmc@vger.kernel.org To: Andrei Warkentin Cc: "Gao, Yunpeng" , "linux-mmc@vger.kernel.org" , "arnd@arndb.de" Hi, On Thu, Apr 14 2011, Andrei Warkentin wrote: > The question to Arnd and Chris - should by default use of CMD23 for > multiblock writes be disabled, and enabled per known-good card using > add_flag quirk support? Or should CMD23 for multiblock writes be > enabled by default, and then disabled for known-bad cards? I don't have a standard answer for this -- it just depends on the numbers. If we've seen a card that freaks out and loses significant bandwidth, that would be a good reason to start with a whitelist. If all the data we have suggests that it's performance-wise either a win or a no-op, that's a fine reason to push it to mmc-next with a blacklist approach and change our minds later if our knowledge gets updated. Does that help? Thanks, - Chris. -- Chris Ball One Laptop Per Child