From owner-freebsd-arm@FreeBSD.ORG Wed Feb 20 18:58:00 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5FF20DD; Wed, 20 Feb 2013 18:58:00 +0000 (UTC) (envelope-from pkelsey@gmail.com) Received: from mail-bk0-f52.google.com (mail-bk0-f52.google.com [209.85.214.52]) by mx1.freebsd.org (Postfix) with ESMTP id 7E573C27; Wed, 20 Feb 2013 18:57:58 +0000 (UTC) Received: by mail-bk0-f52.google.com with SMTP id jk13so3742166bkc.11 for ; Wed, 20 Feb 2013 10:57:52 -0800 (PST) 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=K4OFvzWbMPvHU9Cokdhb/2MY9MxBMs3NMTNg3reFc78=; b=xKuZYBAr8NrdZNMveFp8W+kRZmfvfLsZUP/sGYhNpLzdIcdj7deBFp5uZCqYS6qabs seFmjyKnZTUfPDMHfkiGRA/A1zlsE8KDb3D/PiExo6YpUqDL1WOrCYy5fCTxy2LmwTDk 16p1lYeFJ8i025P1lZT45zk+cc5w+5Ro4pE0yJ/18+KWng4q58BRMW0sM/EyrcdjSxML NGHVzwAgQzWlJkt+3pfUO/5nrTtS3JWXodLBHLfrfJhwZn3MCToRuPSBng0/Tb9Zu4e8 Wg+Wgo1MeL58hvjH2c1Q1Oeu9XO3CgmlbuKjy3lP1DOo0bzIqPGxcY5diYfTYT9HfXfn jjbQ== MIME-Version: 1.0 X-Received: by 10.204.7.194 with SMTP id e2mr9044525bke.104.1361386672228; Wed, 20 Feb 2013 10:57:52 -0800 (PST) Sender: pkelsey@gmail.com Received: by 10.204.128.213 with HTTP; Wed, 20 Feb 2013 10:57:52 -0800 (PST) In-Reply-To: <20130220174449.GB6976@cicely7.cicely.de> References: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> <20130220174449.GB6976@cicely7.cicely.de> Date: Wed, 20 Feb 2013 13:57:52 -0500 X-Google-Sender-Auth: YDGM2A-k-kvBKXx2pO_XkxFZwmE Message-ID: Subject: Re: SPI, _sz fields in struct spi_command From: Patrick Kelsey To: ticso@cicely.de Content-Type: text/plain; charset=ISO-8859-1 Cc: Aleksandr Rybalko , freebsd-arm@freebsd.org, freebsd-mips@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 18:58:00 -0000 On Wed, Feb 20, 2013 at 12:44 PM, Bernd Walter wrote: > On Wed, Feb 20, 2013 at 10:40:35AM -0500, Patrick Kelsey wrote: >> In (1) and (3) above, the drivers for those chips could usefully tell >> the SPI bus interface that they aren't interested in received data >> when transmitting to the SPI-attached devices, and certainly it would >> be at least a small convenience to such SPI interface consumers to >> have the lower level driver handle it. Since not all host-side SPI >> interface hardware supports discarding received data, to allow a >> zero-sized receive buffer in the command passed down, at least some >> SPI interface hardware drivers will have to dynamically allocate or >> maintain a static discard buffer and provide error responses for >> allocation-failure or transfer-too-large. > > If it is SPI hardware drivers decision you at least nee to take into > account that in some RX-only cases you need 0xff dummy data. > The slave chip driver knows if the device parses received data, but > the master chip driver won't. > >> Example (2) is equally easy to handle on either side of the SPI bus >> interface by pointing the transmit buffer pointer at the receive >> buffer. > > This destroys the send data, which is not always welcome behavour. > My comments are in the overall context of extending the functionality of the existing SPI bus interface in ways that provide programming conveniences to those who wish to use them. I am not suggesting in any way that the current interface be narrowed based on any set of assumptions, so in my view, there will always be a facility for fully independent transmit and receive buffers specified by the caller. My example (2) was for a slave device that does not have a data input pin and thus is oblivious to any data sent. Certainly, if you have a device that can receive data sent by the master and your code design calls for preserving the send data across bus transactions, you would continue to use two separate buffers. -Patrick