From owner-freebsd-mips@FreeBSD.ORG Thu Feb 21 02:49:52 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 83B91AA3 for ; Thu, 21 Feb 2013 02:49:52 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ia0-x236.google.com (ia-in-x0236.1e100.net [IPv6:2607:f8b0:4001:c02::236]) by mx1.freebsd.org (Postfix) with ESMTP id 52DFFD5F for ; Thu, 21 Feb 2013 02:49:52 +0000 (UTC) Received: by mail-ia0-f182.google.com with SMTP id k38so1156234iah.41 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=kq1YgE3kOTMl1lmatp3TXVkiOkg0x9byb7/OVJCZRQlVuMe/y2pgo6klC5ELnj9B2E cNgn2nCkNJfwyKvZdY6iBq0Rcwn2vH91Ps+wJC51YQsbHHFKJg4FZoLOzLGT8Y4EZSN2 yDks8vAVfN3JDmnRz9qiyFVx27GRwBVXiaewhix90SsfTEMfMzT5SF7Ro06OzKDkDqQl z0Ap7K6xiWrD1To20FaZMVdkmUBv4OOBbF7zpPJeOmsAh5b/yl/CiJ/KTWI5AfztinhG sRyNwQsaKBQm29ptVDR4DfYG4oQYYjdVQoVCJKfe2VklFOnHJ2p5mKCFlVTcT3tfbN+o LFYg== 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: ALoCoQnoGFgfFv7sIffXs1F+cemxaftFbrvEXiN5tBGbv32R8t/KGtkwevoFavSatu+y+aUL8iKv Cc: freebsd-arm@freebsd.org, ticso@cicely.de, 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: 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