From owner-freebsd-mips@FreeBSD.ORG Fri Apr 5 16:57:28 2013 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5F6C5BA3 for ; Fri, 5 Apr 2013 16:57:28 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by mx1.freebsd.org (Postfix) with ESMTP id EEF4E30B for ; Fri, 5 Apr 2013 16:57:27 +0000 (UTC) Received: by mail-wg0-f53.google.com with SMTP id c11so3941609wgh.8 for ; Fri, 05 Apr 2013 09:57:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=FUjY/kTa0xd5Kp0Whx3phrM4p6NBWcmcDpoLWrTIzWc=; b=J/c3B1fhozV6pXKSNiGkMReyJXsCTBq7qPmEJrpiGGQhJIZVo3Wmeatw0xFMK7tlfB RMkegOSV4qzWfcGJMUMpqJKYDKfGHfOaZUsfDiDpy3HKVyrAI0oZc3tFnxcP+gZ2uBsN FAWYEBTqOA51Ij3euDqwx0iGJq21KQSB9nxWGcEV5jzF3lUGq/AitBx+dogMiyb5Ry2t XeMz0VsPoiXOqrqlGkDwLh57lT2Jb5VHgdanRaHjP8tPheYBOwlssgXxUSTPVQFjzG++ kBja+muL13rorToOWT9iAe8KN4yitqyjcu1hc7UtlI3XmQlco/IQAbUAijOQXO4HsPNM X8PQ== MIME-Version: 1.0 X-Received: by 10.180.73.212 with SMTP id n20mr5721374wiv.11.1365181041188; Fri, 05 Apr 2013 09:57:21 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.212.73 with HTTP; Fri, 5 Apr 2013 09:57:21 -0700 (PDT) In-Reply-To: References: Date: Fri, 5 Apr 2013 09:57:21 -0700 X-Google-Sender-Auth: Wmlete9Gq-EsmnInTop4eaxiFXU Message-ID: Subject: Re: [PATCH] MMC/SD SPI-mode driver From: Adrian Chadd To: Patrick Kelsey Content-Type: text/plain; charset=ISO-8859-1 Cc: Dmytro , freebsd-mips@freebsd.org X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 16:57:28 -0000 On 5 April 2013 07:57, Patrick Kelsey wrote: > My understanding is that in the AR71xx (and possibly other related > Atheros SoCs), the boot flash can be read through memory mapped access > to a region starting at the reset address, as this is how booting from > a serial flash is accomplished. In that scenario, the SPI controller Yes. > will be translating each read access into an SPI bus transaction that > will produce the desired data from the flash. Since the hardware is > performing the SPI signalling, you wouldn't have the CPU overhead of > bitbanging each SPI bit out. Performance would still be limited by > the value set in the SPI clock divider register (which controls the > bit times on the wire) and the speed of the clock that runs the SPI > unit itself. Yes. The problem here is that we're clocking out 8 bits via bit banging, then we read the 8 bits from the Read register. So luckily we don't have to bitbang the reads and writes, but still. The SPI bus code looks pretty simplistic. There's no DELAY() entries in the SPI code either. The only thing we haven't changed is the SPI clock. Now, what Ray at zrouter did was to experiment with turning SPI _flash_ reads into remap-and-memcpy. Look at ath79_spi_do_read_flash_data(). It's a cute hack to improve read performance, but you _absolutely need to know_ that it's a flash chip and that the bus is locked for the duration of the read. You need the SPI bus locked so you don't have someone come along during a transfer loop and try to fiddle with the SPI registers. The other thing that has shown up is that they're doing some transfers in more than 8 bits at a time? That may also help. Thanks, Adrian