From owner-freebsd-mips@FreeBSD.ORG  Wed Apr 10 17:21:29 2013
Return-Path: <owner-freebsd-mips@FreeBSD.ORG>
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 DF44C622;
 Wed, 10 Apr 2013 17:21:29 +0000 (UTC)
 (envelope-from adrian.chadd@gmail.com)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44])
 by mx1.freebsd.org (Postfix) with ESMTP id 25C16B90;
 Wed, 10 Apr 2013 17:21:28 +0000 (UTC)
Received: by mail-wg0-f44.google.com with SMTP id z11so749466wgg.23
 for <multiple recipients>; Wed, 10 Apr 2013 10:21:27 -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=XSAtPrstqgW+8mmA7MKYeC6HF1uTWIXAJVRlOtP2mKI=;
 b=Nlvnv6fyTHqp/853ws64xtsph1SF98Sj/iyXe3it+JFdxH+b+VqZmmQB/83hAQf7MQ
 ggxgkQyEULRCiGIzyO7ZnQpUjSzyzH/E0XCZ5UHYCBT9K75ndxUl9sHJFcSDZH/qQAp3
 FeSBNgvpBaUudbp+RXFfJZWLw50JwF/WXrHm3WJ5+D5keSIdMBQtY7mclLn2ssPUe52m
 mzWAU+GU6EIA88Crujt1yASdEBhcNwNuYRJGf+JPC7+ugK0Z05tlXlp/mHdEspAAaxp1
 KvLlhiPJEduwppGiONRxS7Lw5QtjT0MB2HCQkao1ZSHAoDmUomhvDpEW4k0vRPPfMcqG
 YnJg==
MIME-Version: 1.0
X-Received: by 10.180.109.197 with SMTP id hu5mr4785518wib.22.1365614487816;
 Wed, 10 Apr 2013 10:21:27 -0700 (PDT)
Sender: adrian.chadd@gmail.com
Received: by 10.217.121.136 with HTTP; Wed, 10 Apr 2013 10:21:27 -0700 (PDT)
In-Reply-To: <1365609642.41399.237.camel@revolution.hippie.lan>
References: <CAK1zEjs=hC+pAYBgGq4t7+A_JPLaH6rhvEjD+1RNk1Ziu8E-4g@mail.gmail.com>
 <CAD44qMWpz-sjNKwRH6K=xicFXYutfk7R+N++o7cbgTg7rcQbkA@mail.gmail.com>
 <CAK1zEjuVZU4A59q5GxLcKTnFF9mcrbVmJ=w268uSJ=3sxVf1PA@mail.gmail.com>
 <CAD44qMURrssyXUz-+td226chPA_MbKJ29ZApozbT2cEYbQwSqw@mail.gmail.com>
 <CAJ-Vmo=nQMuuJAW786egjuXCf0LGOd9g+CEEKdOJjPLRQFpKUg@mail.gmail.com>
 <20130407011307.9a9a9d64.ray@freebsd.org>
 <CAJ-Vmo=aeLCmBYpn9YMsGjq+9aF_Es-rByJ3RSnYkJYUECtLuQ@mail.gmail.com>
 <20130407022428.86a66c6a.ray@freebsd.org>
 <CAJ-VmokXseALmvvA9wsgZEBKSP0AGA988592TbsRb+4F0-UEcw@mail.gmail.com>
 <20130408153334.9cc11688aedbf32dcbf83a7b@freebsd.org>
 <CAJ-Vmo=irADrYgM1Aw=fHbnO+gf7kHy_xHeSY9mzTSifo34frg@mail.gmail.com>
 <1365605147.41399.227.camel@revolution.hippie.lan>
 <CAJ-Vmon3v1CV08u7dqn1w=Jwih2eCfjtJdmB_OjZU3cSzx-baA@mail.gmail.com>
 <1365609642.41399.237.camel@revolution.hippie.lan>
Date: Wed, 10 Apr 2013 10:21:27 -0700
X-Google-Sender-Auth: X3D0OTVcdS1CJnaeWvPbUVpszjs
Message-ID: <CAJ-Vmo=+tuHC4WA_5xPtjdJMGMn-_g6p5Nn7YjoPcuqb0s9AKg@mail.gmail.com>
Subject: Re: [PATCH] MMC/SD SPI-mode driver
From: Adrian Chadd <adrian@freebsd.org>
To: Ian Lepore <ian@freebsd.org>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Aleksandr Rybalko <ray@freebsd.org>, Dmytro <dioptimizer@gmail.com>,
 freebsd-mips@freebsd.org
X-BeenThere: freebsd-mips@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Porting FreeBSD to MIPS <freebsd-mips.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-mips>
List-Post: <mailto:freebsd-mips@freebsd.org>
List-Help: <mailto:freebsd-mips-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-mips>,
 <mailto:freebsd-mips-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Apr 2013 17:21:29 -0000

On 10 April 2013 09:00, Ian Lepore <ian@freebsd.org> wrote:

> I don't understand how reading is not a generic spi command
> (presupposing the existance of the proposed changes that allow for a spi
> read without a concurrent write and vice versa).

No. Reading is an SPI method. But the SPI flash command for reading
data is different than other SPI commands.

The only thing we should be doing this for is SPI _flash reads_. Not
SPI reads. Just data area reads from a directly attached flash chip.

It's dirty or inefficient any way we do this. Either we special case
spibus drivers, or we expose a SPI read / SPI write 'command' that
knows it's not a generic SPI bus transaction but specifically a
read-this-flash-data-from-this-offset-and-length transaction. Or some
other kind of dirty hack.



Adrian