From owner-p4-projects@FreeBSD.ORG Wed Oct 4 05:37:39 2006 Return-Path: X-Original-To: p4-projects@freebsd.org Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id EDED416A492; Wed, 4 Oct 2006 05:37:38 +0000 (UTC) X-Original-To: perforce@freebsd.org Delivered-To: perforce@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C027A16A47C for ; Wed, 4 Oct 2006 05:37:38 +0000 (UTC) (envelope-from imp@freebsd.org) Received: from repoman.freebsd.org (repoman.freebsd.org [216.136.204.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 47A0943D58 for ; Wed, 4 Oct 2006 05:37:38 +0000 (GMT) (envelope-from imp@freebsd.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.13.6/8.13.6) with ESMTP id k945bcXb037727 for ; Wed, 4 Oct 2006 05:37:38 GMT (envelope-from imp@freebsd.org) Received: (from perforce@localhost) by repoman.freebsd.org (8.13.6/8.13.4/Submit) id k945bbuU037724 for perforce@freebsd.org; Wed, 4 Oct 2006 05:37:37 GMT (envelope-from imp@freebsd.org) Date: Wed, 4 Oct 2006 05:37:37 GMT Message-Id: <200610040537.k945bbuU037724@repoman.freebsd.org> X-Authentication-Warning: repoman.freebsd.org: perforce set sender to imp@freebsd.org using -f From: Warner Losh To: Perforce Change Reviews Cc: Subject: PERFORCE change 107239 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2006 05:37:39 -0000 http://perforce.freebsd.org/chv.cgi?CH=107239 Change 107239 by imp@imp_lighthouse on 2006/10/04 05:36:42 Don't need a stop command for the simple case of reading a single block. This reduces the number of round trips (commands) by 16 for a 8k transfer. We're down from 34 to 16, or a 53% savings. Multi-block will be the next big win, where we can go all the way down to 2 (start multi-block ... stop at the end). Since we went from 200kB/s to 220kB/s when I doubled the transfer speed, this tells me that 80% of the time isn't affected by the transfer. I hope that the 53% savings will cut the 80% down to 40% which should result in bootsting the speed to something like 400kB/s. We'll see tomorrow if this actually is the case or not. This is a 4 to 1 overhead still. And it is 10x slower than the max transfer rate based solely on clock speed (3.75MB/s). This large factor makes me think that some part of this analysis is flawed. It can't be too fast to do the byte-swapping after the transfers either. 4 bit bus will also help, once I've implemented it, but so long as the non-data portion of the transfers dominates so much, it does little good for the overall numbers. I might be able to get it up to 500k/s by enabling 4-bit bus. This is still well short of the 15MB/s that the clock rate suggests these cards top out at. I'd imagine that multi-block would be a big win... Affected files ... .. //depot/projects/arm/src/sys/dev/mmc/mmcsd.c#9 edit Differences ... ==== //depot/projects/arm/src/sys/dev/mmc/mmcsd.c#9 (text+ko) ==== @@ -173,7 +173,7 @@ memset(&stop, 0, sizeof(stop)); req.cmd = &cmd; cmd.data = &data; - req.stop = &stop; +// req.stop = &stop; if (bp->bio_cmd == BIO_READ) cmd.opcode = MMC_READ_SINGLE_BLOCK; else @@ -189,9 +189,9 @@ data.flags = MMC_DATA_READ; else data.flags = MMC_DATA_WRITE; - stop.opcode = MMC_STOP_TRANSMISSION; - stop.arg = 0; - stop.flags = MMC_RSP_R1B | MMC_CMD_AC; +// stop.opcode = MMC_STOP_TRANSMISSION; +// stop.arg = 0; +// stop.flags = MMC_RSP_R1B | MMC_CMD_AC; MMCBUS_WAIT_FOR_REQUEST(device_get_parent(dev), dev, &req); // XXX error handling