From owner-freebsd-arm@FreeBSD.ORG Thu Feb 21 02:49:52 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 7728FAA2 for ; Thu, 21 Feb 2013 02:49:52 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by mx1.freebsd.org (Postfix) with ESMTP id 47E46D5E for ; Thu, 21 Feb 2013 02:49:52 +0000 (UTC) Received: by mail-ie0-f176.google.com with SMTP id k13so10559127iea.7 for ; Wed, 20 Feb 2013 18:49:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=6b2jKnedNPF9Cwu/vU/LzbSIVdsYrBB9EyaoRU4tJD4=; b=f6mCz1olQez+C7Xpm9gVcU2V580DvLXZxbMCGfkuEFbmGyYJ9Nv6dg2SEAxHPMqZdp AFu/B5e4HG2ikbXBXocSq7AgRFNgJ8wL/nZpgJ6zIvpAME/gTNWqRSbAuSUGCNpyQukP oN4Y7cG5X4WiZvtdW4sGeYio6kNHdWUypMY2ePWmO22FWlv3NWKHeLF79dwEY5KvsZP+ 4sXmS6ziXIB0BgQe3VEJwvDhtO7E3I9D2s9R1TkLL6NcqyQyu8LiPldp1XIJzl1QacAS FmG6Bbbd/ndPWsKsutwZ0MF9oj0DojCdVygm9wYfB6MjMLisHkIkpkzMG7hUyHQ7YGhp HG3A== X-Received: by 10.50.157.138 with SMTP id wm10mr9951446igb.103.1361414991866; Wed, 20 Feb 2013 18:49:51 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id xc3sm15336880igb.10.2013.02.20.18.49.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Feb 2013 18:49:50 -0800 (PST) Sender: Warner Losh Subject: Re: SPI, _sz fields in struct spi_command Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130221022655.6f693eb6.ray@freebsd.org> Date: Wed, 20 Feb 2013 19:49:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <62EDE91B-DDF3-462D-8802-7A7FBF00CE91@bsdimp.com> References: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> <20130220174449.GB6976@cicely7.cicely.de> <20130221022655.6f693eb6.ray@freebsd.org> To: Aleksandr Rybalko X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnCtX41R3UDqQq3C4M55FlZQv5D+EqjrC/BLGLKVCSxIQbP2yofbHPuTKsFvPzCVcpUeGDX Cc: Patrick Kelsey , freebsd-arm@freebsd.org, ticso@cicely.de, 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: Thu, 21 Feb 2013 02:49:52 -0000 On Feb 20, 2013, at 5:26 PM, Aleksandr Rybalko wrote: > On Wed, 20 Feb 2013 13:57:52 -0500 > Patrick Kelsey wrote: >=20 >> 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: >>=20 >>>> 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. >>>=20 >>> 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. >>>=20 >>>> 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. >>>=20 >>> This destroys the send data, which is not always welcome behavour. >>>=20 >>=20 >> 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. >>=20 >> 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. >>=20 >> -Patrick >=20 > Thanks to all for interesting comments, some of my keys for that topic > you all already said but I say it again anyway :) > So why I ask about that: > 1. Do we really need to allocate second unused buffer? Yes, but we could push that requirement into the spi host adapter drivr. > 2. Do we really need to spend clock cycles on that buffer? The way SPI works is that the cycles are spent, because TX cycles have = to equal RX cycles. > 3. Ralink-s SPI can't do bidirectional transfer (IIRC I've tested it > properly, only 1 8bits reg for both RX and TX and same data on read > after TX byte) (Sorry for not commited yet, will do, hope soon :) ) > 4. Since we have sz for both direction and both types (cmd, data) why > controller drivers force us to make it equal? (at91_spi_transfer > KASSERT) Because they must be equal. However, if we're pushing the buffer = management down a level, then we can remove them. > What I think we need to do with that: > 1. remove KASSERT in controller drivers, make driver to accept at = least > cases when (tx_sz =3D=3D rx_sz), (tx_sz && !rx_sz), (!tx_sz && rx_sz). = Plus > if controller require some buffer to drain into it (don't know how to > correctly say in English what men do after many beers :) ) allocate it > or make some static buffer. Yes, moving the responsibility from the driver to the spi controller = would be possible. > 2. teach consumers to give only correct numbers (very nice we have = only > two SPI devices in tree) I thought the at45 was bidirectional... > After that we will be able to make drivers for some (potential) = devices > which will require bidirectional communication. And controllers which > can't do that, will just report error in that. I believe peoples = thinks > before attach such devices to controllers, so we will not have such > incompatibility. If this feature becomes optional, we should have some way for the = controller to communicate that it can do bidirectional transfers. If we = have that, then such a device could refuse to attach on machines with = controllers that can't do htat. > Hope I'm not forget something important :-D No, that's OK. Warner > Thanks to all! >=20 > WBW > --=20 > Aleksandr Rybalko