From owner-freebsd-mips@FreeBSD.ORG Mon Feb 18 11:06:48 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 302A4213 for ; Mon, 18 Feb 2013 11:06:48 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 072B9E2B for ; Mon, 18 Feb 2013 11:06:48 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r1IB6lS4061603 for ; Mon, 18 Feb 2013 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r1IB6ld8061601 for freebsd-mips@FreeBSD.org; Mon, 18 Feb 2013 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 18 Feb 2013 11:06:47 GMT Message-Id: <201302181106.r1IB6ld8061601@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-mips@FreeBSD.org Subject: Current problem reports assigned to 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: Mon, 18 Feb 2013 11:06:48 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/165951 mips [ar913x] [ath] DDR flush isn't being done for the WMAC p kern/163670 mips [mips][arge] arge can't allocate ring buffer on multip 2 problems total. From owner-freebsd-mips@FreeBSD.ORG Mon Feb 18 14:32:09 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 5CD19379 for ; Mon, 18 Feb 2013 14:32:09 +0000 (UTC) (envelope-from mukunda@pointred.co) Received: from na3sys010aog104.obsmtp.com (na3sys010aog104.obsmtp.com [74.125.245.76]) by mx1.freebsd.org (Postfix) with SMTP id 0E90DDA for ; Mon, 18 Feb 2013 14:32:08 +0000 (UTC) Received: from mail-gh0-f200.google.com ([209.85.160.200]) (using TLSv1) by na3sys010aob104.postini.com ([74.125.244.12]) with SMTP ID DSNKUSI7aAp9YdQrIEbSpLKmwcCUnHp6XzPV@postini.com; Mon, 18 Feb 2013 06:32:09 PST Received: by mail-gh0-f200.google.com with SMTP id 10so4183382ghy.11 for ; Mon, 18 Feb 2013 06:32:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=pXri/CMRBRkE8ImxKyPDzU3vAWFrw3ZAUfPCdZmCn9k=; b=M2agCgol/vmRDYCRRJXiAIlncxauwh5LFWU1JCsGG+WwJcVzx+PKO9SttCIdwIGy+n PP4cT6Z0H4UA4eEA1ZslvMp6HKPFI57/cWzVlnOOKDNa3pdqyQh+Cr4yeH/EDq9AONJP 4nGUUMqu5CsF8sQYVbrNGtkJG/rFJXSgJ+lNbu/kGRB9b1c5EqJhGnZBuuK/uHPRrT2y QQngsPcStg/dF04MTJJ0viuLp8UNdfl/fTDVZ2LpaRqGhpOIxh08agi/mxSQx0BtUSvy svNlNEQFqLBfGOnNXB+HVXvNpVMIneRmdXBMSc3agjHZDrf12IGlzB0etXzoafkPlI02 eEzA== X-Received: by 10.58.23.169 with SMTP id n9mr15060932vef.58.1361187110074; Mon, 18 Feb 2013 03:31:50 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.58.23.169 with SMTP id n9mr15060924vef.58.1361187109924; Mon, 18 Feb 2013 03:31:49 -0800 (PST) Received: by 10.220.205.11 with HTTP; Mon, 18 Feb 2013 03:31:49 -0800 (PST) Date: Mon, 18 Feb 2013 17:01:49 +0530 Message-ID: Subject: WiFi TDMA AR7161, results and moving forward From: Mukunda Haveri To: Adrian Chadd , freebsd-mips@freebsd.org X-Gm-Message-State: ALoCoQnUcTuWgaJcHJPhDKMWFpSslqQjISBWaAFGogvzRSr+5hPhC3eK35q6UT0PwlNuzJpqTK0W6KhaRYBCD06QBHcgx9XWQUSXoj6TBs2+et9c5ZgiAEoVFSRORzlFhyYVbH7GO7a1RIbG6litD2IrOSOWJN2ecjyX2pJo8hrtXeJwnshxHFg= Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 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: Mon, 18 Feb 2013 14:32:09 -0000 Thanks to Adrian's WiFi scripts, we were able to get the TDMA working on the Compex-AR7161 board. The results were surprising; we are able to do, close to 100 mbps one way iperf tests and 40 mbps bidirectional Iperf in non-TDMA mode. We were able to achieve this, only after disabling all the debug options in the kernel. Porting the U-Boot to the Compex-boards did take lot of effort, but not the "FreeBsd". Many thanks to all the "scientists" who made this possible. Moving forward, it is observed that the TDMA throughput peaks at 9 mbps and refuses to move beyond. After reducing the slot duration to 1 ms, the throughput increased to around 12 mbps. I was expecting the TDMA to yield a better throughput because of collision-less scheme. I would like to understand if our observation is expected or if there's some inherent limitation within the TDMA controller. It will be good to have some feedback from TDMers with similar experience or better. Thanks again, HSM DISCLAIMER: The information contained in this message (including any attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and permanently delete this message and any attachments from your system. Any dissemination, use, review, distribution, printing or copying of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. PointRed Telecom Ltd (including its group companies) shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt or damage to your system and does not guarantee that the integrity of this communication has been maintained or that this communication is free of viruses, interceptions or interferences. From owner-freebsd-mips@FreeBSD.ORG Mon Feb 18 21:28:41 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 1CE9CE7C; Mon, 18 Feb 2013 21:28:41 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 8BDD48A2; Mon, 18 Feb 2013 21:28:40 +0000 (UTC) Received: by mail-we0-f171.google.com with SMTP id u54so4999040wey.2 for ; Mon, 18 Feb 2013 13:28:39 -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=UsrifQAl1xF1LBGERtjtMIEqqGym930N1vg+frf2hrI=; b=vgF9H6XBxkMirKWnKOxqOJ4ITygY9qYmGd2xQFSnQAIGAqJDWYgUT/n4TtTsFqCkz2 NlGtGxPNCa7szJRzmOnhabGTiqSZE1L7Jkw4pdCVLADhMwJpP4IHyhZH3AuRyPaio05j eGi7iTA/S7t/cvQfXlsQ7tGflEBkkZMtCQxWBr2FUGe52ifKR+0SGhOBYyRzT7KK/xyJ iaRjFLgnIsXt3TDeY/hVW7OBOFhG3FYGBDEBOMWU23mxyP7L7eldthVE7cQmDzPioRjZ fMLqtA6TA1eARJ5Z0QYQSJSpTArq9d5BszToFLOZwdMK9lxCTZyk0BHeNRyfvT+y2Z0a UE3w== MIME-Version: 1.0 X-Received: by 10.180.84.165 with SMTP id a5mr23275696wiz.6.1361222919799; Mon, 18 Feb 2013 13:28:39 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.236.88 with HTTP; Mon, 18 Feb 2013 13:28:39 -0800 (PST) In-Reply-To: References: Date: Mon, 18 Feb 2013 13:28:39 -0800 X-Google-Sender-Auth: RjmfwrzQ8zaK0hYP4H9kIIrKgtI Message-ID: Subject: Re: WiFi TDMA AR7161, results and moving forward From: Adrian Chadd To: Mukunda Haveri Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org, 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: Mon, 18 Feb 2013 21:28:41 -0000 On 18 February 2013 03:31, Mukunda Haveri wrote: > > Thanks to Adrian's WiFi scripts, we were able to get the TDMA working on the > Compex-AR7161 board. The results were surprising; we are able to do, close > to 100 mbps one way iperf tests and 40 mbps bidirectional Iperf in non-TDMA > mode. We were able to achieve this, only after disabling all the debug > options in the kernel. Porting the U-Boot to the Compex-boards did take lot > of effort, but not the "FreeBsd". Many thanks to all the "scientists" who > made this possible. Nice! Which wireless cards are you using? > Moving forward, it is observed that the TDMA throughput peaks at 9 mbps and > refuses to move beyond. After reducing the slot duration to 1 ms, the > throughput increased to around 12 mbps. I was expecting the TDMA to yield a > better throughput because of collision-less scheme. I would like to > understand if our observation is expected or if there's some inherent > limitation within the TDMA controller. > > It will be good to have some feedback from TDMers with similar experience or > better. Right now the TDMA code doesn't implement MCS rates or TX aggregation. Thus you're not going to get 11n like throughput. The first thing to implement is allowing for MCS rates (non-aggregation) and make sure all the packet duration calculations are being done "right". After that, we need to implement delayed blockack support in net80211 and the ath driver. That requires the stack to support handling BA requests/responses and ath(4) to mark all frame descriptors in a delayed-BA TID to be no-ack. Once that's done, we can tie it all together to make it work over TDMA. :-) Thanks, Adrian From owner-freebsd-mips@FreeBSD.ORG Wed Feb 20 12:21:22 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 76466328; Wed, 20 Feb 2013 12:21:22 +0000 (UTC) (envelope-from ray@freebsd.org) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 3B3B1D95; Wed, 20 Feb 2013 12:21:22 +0000 (UTC) Received: from terran (unknown [192.168.99.1]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPA id 7D4C3C493A; Wed, 20 Feb 2013 14:21:20 +0200 (EET) Date: Wed, 20 Feb 2013 14:21:40 +0200 From: Aleksandr Rybalko To: freebsd-arm@freebsd.org, freebsd-mips@freebsd.org Subject: SPI, _sz fields in struct spi_command Message-Id: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> X-Mailer: Sylpheed 3.2.0 (GTK+ 2.24.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: Wed, 20 Feb 2013 12:21:22 -0000 Hello ARM and MIPS hackers! Sorry for cross-post, but we have supported SPI devices on both platforms (and seems no others). Anyone know any reasons to keep both TX and RX _sz fields with same values? sys/dev/flash/at45d.c static int at45d_get_mfg_info(device_t dev, uint8_t *resp) { ... cmd.tx_cmd_sz = cmd.rx_cmd_sz = 5; ... } or sys/dev/flash/mx25l.c static int mx25l_read(device_t dev, off_t offset, caddr_t data, off_t count) { ... cmd.tx_cmd_sz = 5; cmd.rx_cmd_sz = 5; ... } That always require second but unused buffer or writable tx buffer. And not all controllers able to TX with RX same time. (at least rt305x can't). So if nobody have any objections, I will update drivers (SPI controllers and SPI attached devices) to set unused _sz field to zero. IIRC, I will require help with AT91 controller update, at least with testing. Thanks. WBW -- Aleksandr Rybalko From owner-freebsd-mips@FreeBSD.ORG Wed Feb 20 14:15:51 2013 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DFE50598 for ; Wed, 20 Feb 2013 14:15:51 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ia0-x230.google.com (mail-ia0-x230.google.com [IPv6:2607:f8b0:4001:c02::230]) by mx1.freebsd.org (Postfix) with ESMTP id B344D708 for ; Wed, 20 Feb 2013 14:15:51 +0000 (UTC) Received: by mail-ia0-f176.google.com with SMTP id i18so7028784iac.7 for ; Wed, 20 Feb 2013 06:15:51 -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=O8Jeiq/iupp3/DNz14CvZFGlsEnTE3MXGh9GIdzcqD4=; b=gPuUd22xf03cCsFw07GVDM4TyLMrRIGPLIpVGiO2Z4uaflmYneZwb+D7tUHaVoDHZx eWsGxzW6mQPyDSTjREw7fHK6WR+auP+P87UR8dcmhaM7Q+IMzzDfCbUY/igO9a5/CnLx MoOOMCr5NDJe2vqyfGHUaopg5T6hj5Rgn97/Rfa30wQxL/xLMRICixP3uenkU3AVcSNF GWFBZsbwFsuWvYPhmuoe8h0SSmyedYWLyNKnjqln+ZKYrBvYt/VjO/DtdHGkdaRFcif0 qdZChQM+hL4KL+kPkxTNmuzorMA4JbaHVLres/402bxRT4haaXU0vJk7L5pk2HuTgRKf wBLA== X-Received: by 10.43.8.200 with SMTP id ot8mr9298733icb.11.1361369751261; Wed, 20 Feb 2013 06:15: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 wv1sm13816863igb.0.2013.02.20.06.15.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Feb 2013 06:15: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: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> Date: Wed, 20 Feb 2013 07:15:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> References: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> To: Aleksandr Rybalko X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnNzyrafJWkFHpHzRa3XF1wLuVQfQBkR0URm8tEJVJTDjew85eJRgPzanOSLiKvJDnGjFtl Cc: freebsd-arm@freebsd.org, 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: Wed, 20 Feb 2013 14:15:51 -0000 On Feb 20, 2013, at 5:21 AM, Aleksandr Rybalko wrote: > Hello ARM and MIPS hackers! >=20 > Sorry for cross-post, but we have supported SPI devices on both > platforms (and seems no others). >=20 > Anyone know any reasons to keep both TX and RX _sz fields with same > values? I wrote them to be separate for a reason.... I think I'd thought = there'd be cases when you'd want to throw away the results or transmit = garbage... I can't think of why right now... > sys/dev/flash/at45d.c > static int > at45d_get_mfg_info(device_t dev, uint8_t *resp) > { > ... > cmd.tx_cmd_sz =3D cmd.rx_cmd_sz =3D 5; > ... > } >=20 > or sys/dev/flash/mx25l.c > static int > mx25l_read(device_t dev, off_t offset, caddr_t data, off_t count) > { > ... > cmd.tx_cmd_sz =3D 5; > cmd.rx_cmd_sz =3D 5; > ... > } >=20 > That always require second but unused buffer or writable tx buffer. = And > not all controllers able to TX with RX same time. (at least rt305x > can't). So if nobody have any objections, I will update drivers (SPI > controllers and SPI attached devices) to set unused _sz field to zero. > IIRC, I will require help with AT91 controller update, at least with > testing. The AT91, I think, required a minimum size, which is why the at45d = driver set it I think.. I can't imagine an SPI controller that can't do both, because when you = write something with SPI, you usually have to read back the status at = the same time... Warner > Thanks. >=20 > WBW > --=20 > Aleksandr Rybalko > _______________________________________________ > freebsd-mips@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mips > To unsubscribe, send any mail to = "freebsd-mips-unsubscribe@freebsd.org" From owner-freebsd-mips@FreeBSD.ORG Wed Feb 20 14:32:27 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 3C74ADA9; Wed, 20 Feb 2013 14:32:27 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id C23C87EF; Wed, 20 Feb 2013 14:32:26 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r1KEWDUH022958; Wed, 20 Feb 2013 07:32:19 -0700 (MST) (envelope-from ian@FreeBSD.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r1KEWAKT051400; Wed, 20 Feb 2013 07:32:10 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: SPI, _sz fields in struct spi_command From: Ian Lepore To: Warner Losh In-Reply-To: <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> References: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> Content-Type: text/plain; charset="us-ascii" Date: Wed, 20 Feb 2013 07:32:10 -0700 Message-ID: <1361370730.1185.10.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Aleksandr Rybalko , freebsd-arm@FreeBSD.org, 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: Wed, 20 Feb 2013 14:32:27 -0000 On Wed, 2013-02-20 at 07:15 -0700, Warner Losh wrote: > On Feb 20, 2013, at 5:21 AM, Aleksandr Rybalko wrote: > > > Hello ARM and MIPS hackers! > > > > Sorry for cross-post, but we have supported SPI devices on both > > platforms (and seems no others). > > > > Anyone know any reasons to keep both TX and RX _sz fields with same > > values? > > I wrote them to be separate for a reason.... I think I'd thought there'd be cases when you'd want to throw away the results or transmit garbage... I can't think of why right now... > > > sys/dev/flash/at45d.c > > static int > > at45d_get_mfg_info(device_t dev, uint8_t *resp) > > { > > ... > > cmd.tx_cmd_sz = cmd.rx_cmd_sz = 5; > > ... > > } > > > > or sys/dev/flash/mx25l.c > > static int > > mx25l_read(device_t dev, off_t offset, caddr_t data, off_t count) > > { > > ... > > cmd.tx_cmd_sz = 5; > > cmd.rx_cmd_sz = 5; > > ... > > } > > > > That always require second but unused buffer or writable tx buffer. And > > not all controllers able to TX with RX same time. (at least rt305x > > can't). So if nobody have any objections, I will update drivers (SPI > > controllers and SPI attached devices) to set unused _sz field to zero. > > IIRC, I will require help with AT91 controller update, at least with > > testing. > > The AT91, I think, required a minimum size, which is why the at45d driver set it I think.. > > I can't imagine an SPI controller that can't do both, because when you write something with SPI, you usually have to read back the status at the same time... > > Warner I think with at91 you really must do same-sized xfers in both directions or you'll get underflow/overflow errors from the hardware. It might be possible to just ignore the error, but even then the only useful way the xfer sizes could be different is one of them would be zero. Different non-zero sizes just don't make sense. -- Ian From owner-freebsd-mips@FreeBSD.ORG Wed Feb 20 14:34:46 2013 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C85A3FFD for ; Wed, 20 Feb 2013 14:34:46 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by mx1.freebsd.org (Postfix) with ESMTP id 8F411822 for ; Wed, 20 Feb 2013 14:34:46 +0000 (UTC) Received: by mail-gh0-f172.google.com with SMTP id z22so1028312ghb.31 for ; Wed, 20 Feb 2013 06:34:40 -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=CfxLiBkDogwmfMBNAqUcez0T4zMSq1Zl8A51IBnyml8=; b=XwzEmDAnC3Xz4TspjVAcPOjYbx/4sT74kPzObz8lHP5u6K3oAILnZcgMxbmFF7TgTZ UOwuIXXUmOcPdfMjOcvdoKqK6KtKR/UXhWSAYlK9W8wcmFKB8UAehr9rGy0f2BSjxZxI O4mBBA0SFBw0bCZYt5ATzQIZPwXX8E5TOQPZyLPzrA0EpfRaVWH6607b+6AdsvNBBQxS J+lUiW2QzSFMFa6uHPuB/Oioq+OvJRChV67UIkvn1svOdbzdeb6SItMq4WJR4Up+kvU1 t67b9blxTufoYf7cfIyBbvYgihh1Vtu9WGN4Zic6bY9h/m7s9aCIcEyPXu/7EgGt90uI F4Ow== X-Received: by 10.236.77.69 with SMTP id c45mr36575221yhe.65.1361370880254; Wed, 20 Feb 2013 06:34:40 -0800 (PST) Received: from [10.30.30.100] ([209.117.142.2]) by mx.google.com with ESMTPS id t8sm69514043anj.2.2013.02.20.06.34.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Feb 2013 06:34:39 -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: <1361370730.1185.10.camel@revolution.hippie.lan> Date: Wed, 20 Feb 2013 07:34:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5C3022E6-AEDB-4403-B5C1-E6EA6F9451EE@bsdimp.com> References: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> <1361370730.1185.10.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQkX2zS6K8MKxESOpZTI1hJbj6tRslxupd7IfRer47rtOOIJF9N+8pbpgaI61KNZymkZZk6W Cc: Aleksandr Rybalko , freebsd-arm@FreeBSD.org, 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: Wed, 20 Feb 2013 14:34:46 -0000 On Feb 20, 2013, at 7:32 AM, Ian Lepore wrote: > On Wed, 2013-02-20 at 07:15 -0700, Warner Losh wrote: >> On Feb 20, 2013, at 5:21 AM, Aleksandr Rybalko wrote: >>=20 >>> Hello ARM and MIPS hackers! >>>=20 >>> Sorry for cross-post, but we have supported SPI devices on both >>> platforms (and seems no others). >>>=20 >>> Anyone know any reasons to keep both TX and RX _sz fields with same >>> values? >>=20 >> I wrote them to be separate for a reason.... I think I'd thought = there'd be cases when you'd want to throw away the results or transmit = garbage... I can't think of why right now... >>=20 >>> sys/dev/flash/at45d.c >>> static int >>> at45d_get_mfg_info(device_t dev, uint8_t *resp) >>> { >>> ... >>> cmd.tx_cmd_sz =3D cmd.rx_cmd_sz =3D 5; >>> ... >>> } >>>=20 >>> or sys/dev/flash/mx25l.c >>> static int >>> mx25l_read(device_t dev, off_t offset, caddr_t data, off_t count) >>> { >>> ... >>> cmd.tx_cmd_sz =3D 5; >>> cmd.rx_cmd_sz =3D 5; >>> ... >>> } >>>=20 >>> That always require second but unused buffer or writable tx buffer. = And >>> not all controllers able to TX with RX same time. (at least rt305x >>> can't). So if nobody have any objections, I will update drivers (SPI >>> controllers and SPI attached devices) to set unused _sz field to = zero. >>> IIRC, I will require help with AT91 controller update, at least with >>> testing. >>=20 >> The AT91, I think, required a minimum size, which is why the at45d = driver set it I think.. >>=20 >> I can't imagine an SPI controller that can't do both, because when = you write something with SPI, you usually have to read back the status = at the same time... >>=20 >> Warner >=20 > I think with at91 you really must do same-sized xfers in both = directions > or you'll get underflow/overflow errors from the hardware. It might = be > possible to just ignore the error, but even then the only useful way = the > xfer sizes could be different is one of them would be zero. Different > non-zero sizes just don't make sense. Does 0 really work? I have a vague memory of trying to allow it when I = first wrote the driver and having it fail badly on the AT91RM9200... Warner Warner= From owner-freebsd-mips@FreeBSD.ORG Wed Feb 20 15:40:43 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 B0CCDBF4; Wed, 20 Feb 2013 15:40:43 +0000 (UTC) (envelope-from pkelsey@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id EC78FCC6; Wed, 20 Feb 2013 15:40:42 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id w5so3650741bku.41 for ; Wed, 20 Feb 2013 07:40:35 -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=m+WdbAMqzsgRumh3e3jmtmrXXf8Dn7GRCzcUIjWWvjM=; b=g3Zi8GZrT1nGhqakwXTTu45AFl/m/7fUMcCe+WdXEWEIGoPRnFNVorx5Q7DZs3lQ5D SxXIb0jbR0FNxSrQm8wc+4zkRFZDqLrg6JuJg813+GfkMG/AtjWj3GGleMS8YMWI7hmY jElN1PkCJHXN9/UNiMcLCJ+z4XLmI0dOLFzpQtW+Efb1L+/L1RceB7s6sxZSHqOPKCah cjBKpj8a/aJ2AJRPp79WSSRXpwO6h2EN31X2hT4wX+uFGMs84HH1gvXCgdQUILpf0GQ5 SBs9h+js7aenKORNFtMhqjf84alT9pLk8FasDap4JQXiviISiorTCD0D/0/92HeJtVcC /OdQ== MIME-Version: 1.0 X-Received: by 10.204.157.150 with SMTP id b22mr8698173bkx.121.1361374835653; Wed, 20 Feb 2013 07:40:35 -0800 (PST) Sender: pkelsey@gmail.com Received: by 10.204.128.213 with HTTP; Wed, 20 Feb 2013 07:40:35 -0800 (PST) In-Reply-To: <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> References: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> Date: Wed, 20 Feb 2013 10:40:35 -0500 X-Google-Sender-Auth: uAkPZC0wQlwq2st81GnLl6O_EMk Message-ID: Subject: Re: SPI, _sz fields in struct spi_command From: Patrick Kelsey To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Cc: Aleksandr Rybalko , freebsd-arm@freebsd.org, 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: Wed, 20 Feb 2013 15:40:43 -0000 On Wed, Feb 20, 2013 at 9:15 AM, Warner Losh wrote: > > > On Feb 20, 2013, at 5:21 AM, Aleksandr Rybalko wrote: > > > Hello ARM and MIPS hackers! > > > > Sorry for cross-post, but we have supported SPI devices on both > > platforms (and seems no others). > > > > Anyone know any reasons to keep both TX and RX _sz fields with same > > values? > > I wrote them to be separate for a reason.... I think I'd thought there'd be cases when you'd want to throw away the results or transmit garbage... I can't think of why right now... Per the spec, there is always a data bit available to be received on the bus for each data bit clocked out. Per the application, all of those bits are not always of interest. There are a few examples that exist in the world that I am aware of where the data transmitted or received on the SPI bus is of no interest to at least one participant in the transaction: 1. Some devices only implement SDI. One example would be a low cost/low pin count DAC such as the AD5662. In this case, the host would never be interested in the data received from the SPI bus during transmissions to the DAC. 2. Some devices only implement SDO. One example would be a low cost/low pin count ADC, such as the AD7091. In this case, the host could safely transmit undefined data on the bus when retrieving data from the ADC. 3. The protocol that rides on the SPI is in whole or in part half duplex. (a) The protocol for talking to MMC/SD cards over SPI is entirely half duplex. When information is sent to the card from the host, all bits received from the card during the transmission are discarded. When the host wants to read data from the card, it transmits all ones bits. (b) At least some Broadcom switch chips provide no meaningful receive data during command transmit. 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. 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. -Patrick From owner-freebsd-mips@FreeBSD.ORG Wed Feb 20 18:12:19 2013 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0AF51BD4; Wed, 20 Feb 2013 18:12:19 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id A95C5941; Wed, 20 Feb 2013 18:12:18 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id r1KHjjfT009591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 Feb 2013 18:45:46 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id r1KHinKS040719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Feb 2013 18:44:50 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id r1KHinwH010874; Wed, 20 Feb 2013 18:44:49 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id r1KHintA010873; Wed, 20 Feb 2013 18:44:49 +0100 (CET) (envelope-from ticso) Date: Wed, 20 Feb 2013 18:44:49 +0100 From: Bernd Walter To: Patrick Kelsey Subject: Re: SPI, _sz fields in struct spi_command Message-ID: <20130220174449.GB6976@cicely7.cicely.de> References: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: Aleksandr Rybalko , freebsd-arm@freebsd.org, freebsd-mips@freebsd.org X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 18:12:19 -0000 On Wed, Feb 20, 2013 at 10:40:35AM -0500, Patrick Kelsey wrote: > On Wed, Feb 20, 2013 at 9:15 AM, Warner Losh wrote: > > > > > > On Feb 20, 2013, at 5:21 AM, Aleksandr Rybalko wrote: > > > > > Hello ARM and MIPS hackers! > > > > > > Sorry for cross-post, but we have supported SPI devices on both > > > platforms (and seems no others). > > > > > > Anyone know any reasons to keep both TX and RX _sz fields with same > > > values? > > > > I wrote them to be separate for a reason.... I think I'd thought there'd be cases when you'd want to throw away the results or transmit garbage... I can't think of why right now... > > > Per the spec, there is always a data bit available to be received on > the bus for each data bit clocked out. Per the application, all of > those bits are not always of interest. There are a few examples that > exist in the world that I am aware of where the data transmitted or > received on the SPI bus is of no interest to at least one participant > in the transaction: > > 1. Some devices only implement SDI. One example would be a low > cost/low pin count DAC such as the AD5662. In this case, the host > would never be interested in the data received from the SPI bus during > transmissions to the DAC. > > 2. Some devices only implement SDO. One example would be a low > cost/low pin count ADC, such as the AD7091. In this case, the host > could safely transmit undefined data on the bus when retrieving data > from the ADC. > > 3. The protocol that rides on the SPI is in whole or in part half duplex. > (a) The protocol for talking to MMC/SD cards over SPI is entirely > half duplex. When information is sent to the card from the host, all > bits received from the card during the transmission are discarded. > When the host wants to read data from the card, it transmits all ones > bits. > (b) At least some Broadcom switch chips provide no meaningful > receive data during command transmit. The AT91 SPI always has data for both directions. It has a register for word to send and a register for words received. With DMA you tell to automatically fill/empty those registers from/to one memory region. You have two DMA buffers for each direction, so you can interleave. They are automatically switched and you can recofigure the other. If e.g. you only have something to send and only supply a DMA buffer for send data, then the RX register gets filled, but never emptied. There is no overflow in master mode, the controller just stops until you empty the register. You can either empty each time with single interrupt overhead or supply some DMA memory as bit bucket. Same with RX-only - you need to fill the send register with dummy data, so easiest is to supply a dummy DMA-buffer. Some devices expect the dummy send buffer to be filled with 0xff, so that they don't interet it as a command. Supplying dummy memory for DMA hurts for large transfers, but seems to be unavoidable with some hardware. With the AT91 SPI you can use smaller dummy buffers and interleave them to reduce memory requirement, but I think the OS overhead is to big. > 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. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-mips@FreeBSD.ORG Wed Feb 20 18:58:00 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 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-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: 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 From owner-freebsd-mips@FreeBSD.ORG Thu Feb 21 00:27:17 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 B9216651; Thu, 21 Feb 2013 00:27:17 +0000 (UTC) (envelope-from ray@freebsd.org) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 3DCC97F1; Thu, 21 Feb 2013 00:27:16 +0000 (UTC) Received: from rnote.ddteam.net (102-43-135-95.pool.ukrtel.net [95.135.43.102]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id 24AB1C4930; Thu, 21 Feb 2013 02:27:09 +0200 (EET) Date: Thu, 21 Feb 2013 02:26:55 +0200 From: Aleksandr Rybalko To: Patrick Kelsey Subject: Re: SPI, _sz fields in struct spi_command Message-Id: <20130221022655.6f693eb6.ray@freebsd.org> In-Reply-To: References: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> <20130220174449.GB6976@cicely7.cicely.de> Organization: FreeBSD.ORG X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) X-Operating-System: FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 00:27:17 -0000 On Wed, 20 Feb 2013 13:57:52 -0500 Patrick Kelsey wrote: > 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 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? 2. Do we really need to spend clock cycles on that buffer? 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) 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 == 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. 2. teach consumers to give only correct numbers (very nice we have only two SPI devices in tree) 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. Hope I'm not forget something important :-D Thanks to all! WBW -- Aleksandr Rybalko From owner-freebsd-mips@FreeBSD.ORG Thu Feb 21 01:44:48 2013 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 05405735; Thu, 21 Feb 2013 01:44:48 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 62EBAA78; Thu, 21 Feb 2013 01:44:46 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id r1L1iatg021259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Feb 2013 02:44:37 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id r1L1iYn6054286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2013 02:44:34 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id r1L1iXo5012875; Thu, 21 Feb 2013 02:44:33 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id r1L1iXVK012874; Thu, 21 Feb 2013 02:44:33 +0100 (CET) (envelope-from ticso) Date: Thu, 21 Feb 2013 02:44:33 +0100 From: Bernd Walter To: Aleksandr Rybalko Subject: Re: SPI, _sz fields in struct spi_command Message-ID: <20130221014433.GA12189@cicely7.cicely.de> References: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> <20130220174449.GB6976@cicely7.cicely.de> <20130221022655.6f693eb6.ray@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130221022655.6f693eb6.ray@freebsd.org> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de 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 Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 01:44:48 -0000 On Thu, Feb 21, 2013 at 02:26:55AM +0200, Aleksandr Rybalko wrote: > On Wed, 20 Feb 2013 13:57:52 -0500 > Patrick Kelsey wrote: > > > 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 > > 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? For AT91 yes, unless: - RX-only and you know that sending the RX buffers undefined content is Ok, which is not if the device needs 0xff - TX-only and you know that trashing the TX buffer is Ok > 2. Do we really need to spend clock cycles on that buffer? For AT91 it is required, others maybe not. > 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) They can't otherwise. > 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 == 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. Sounds good. Static buffers however may require multiple DMA setup if the transfer request ist bigger. With AT91 this can be done via *empty interrupt to replay the same buffer. It is just not wise to interrupt on each single byte, which would be required without a DMA buffer at all. Sending 0xff as default dummy data requires filling the TX buffer with this value, so maybe if doing static then have 2 buffers, one with 0xff dummy data and one bit-bucket buffer to RX into. Otherwise use the same dummy data and if a driver requires sending dummy 0xff it needs to supply its own buffer, but there are many devices requiring this. > 2. teach consumers to give only correct numbers (very nice we have only > two SPI devices in tree) > > 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. I don't think there are many devices requiring RX/TX at the same time. And if a controller won't support it there is nothing to be done anyway beside bit bang-ing. But I usually do RX/TX at the same transfer with devices wanting a comand word and then sending data at the next data word. In many cases you must not deassert CS during this. I don't know how CS is handled in our SPI as I never did SPI with FreeBSD. If CS is handled automatically on each transaction then it must support bidirectional transactions. If CS however are done with separate calls it is Ok to do a TX and then an TX call before deasserting. The AT91 hardware has automatic CS support - in my own controller code outside of FreeBSD I usually prefer handling CS with GPIO for that reason. > Hope I'm not forget something important :-D > > Thanks to all! > > WBW > -- > Aleksandr Rybalko -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. 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 From owner-freebsd-mips@FreeBSD.ORG Thu Feb 21 14:16:12 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 59EC95E4; Thu, 21 Feb 2013 14:16:12 +0000 (UTC) (envelope-from ray@freebsd.org) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id A51F377C; Thu, 21 Feb 2013 14:16:11 +0000 (UTC) Received: from terran (unknown [192.168.99.1]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPA id 6B1E7C4950; Thu, 21 Feb 2013 16:16:04 +0200 (EET) Date: Thu, 21 Feb 2013 16:16:27 +0200 From: Aleksandr Rybalko To: Warner Losh Subject: Re: SPI, _sz fields in struct spi_command Message-Id: <20130221161627.478d35aa88c95c03cafb00a7@freebsd.org> In-Reply-To: <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> <62EDE91B-DDF3-462D-8802-7A7FBF00CE91@bsdimp.com> X-Mailer: Sylpheed 3.2.0 (GTK+ 2.24.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 14:16:12 -0000 On Wed, 20 Feb 2013 19:49:20 -0700 Warner Losh wrote: > > On Feb 20, 2013, at 5:26 PM, Aleksandr Rybalko wrote: > > > On Wed, 20 Feb 2013 13:57:52 -0500 > > Patrick Kelsey wrote: > > > >> 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 > > > > 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. I understand how it works, I'm about allocating/zeroing/etc for that buffer. :) > > > 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. They must be equal for controller, but it's good to have way to hint controller about "we don't need to RX anything, so take care your requirements yourself" :) So at91_spi will use some own buffer for that case, but other controllers will not spend time on that buffer. > > > 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 == 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. Yep > > > 2. teach consumers to give only correct numbers (very nice we have only > > two SPI devices in tree) > > I thought the at45 was bidirectional... Nope, all transfers fill some part of tx buffer, then read on offset=sizeof(some part) of rx buffer. > > > 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. In the normal world nobody produce systems which have incompatible parts :) > > > Hope I'm not forget something important :-D > > No, that's OK. > > Warner > > > Thanks to all! > > > > WBW > > -- > > Aleksandr Rybalko > -- Aleksandr Rybalko From owner-freebsd-mips@FreeBSD.ORG Thu Feb 21 14:30:05 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 0BABADDA; Thu, 21 Feb 2013 14:30:05 +0000 (UTC) (envelope-from ray@freebsd.org) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 6B03D8BA; Thu, 21 Feb 2013 14:30:04 +0000 (UTC) Received: from terran (unknown [192.168.99.1]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPA id EBE9EC4950; Thu, 21 Feb 2013 16:30:02 +0200 (EET) Date: Thu, 21 Feb 2013 16:30:26 +0200 From: Aleksandr Rybalko To: ticso@cicely.de Subject: Re: SPI, _sz fields in struct spi_command Message-Id: <20130221163026.dbeb03f9c38de3d24a7ab30f@freebsd.org> In-Reply-To: <20130221014433.GA12189@cicely7.cicely.de> References: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> <20130220174449.GB6976@cicely7.cicely.de> <20130221022655.6f693eb6.ray@freebsd.org> <20130221014433.GA12189@cicely7.cicely.de> X-Mailer: Sylpheed 3.2.0 (GTK+ 2.24.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, Bernd Walter , 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 14:30:05 -0000 On Thu, 21 Feb 2013 02:44:33 +0100 Bernd Walter wrote: > On Thu, Feb 21, 2013 at 02:26:55AM +0200, Aleksandr Rybalko wrote: > > On Wed, 20 Feb 2013 13:57:52 -0500 > > Patrick Kelsey wrote: > > > > > 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 > > > > 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? > > For AT91 yes, unless: > - RX-only and you know that sending the RX buffers undefined content is Ok, > which is not if the device needs 0xff > - TX-only and you know that trashing the TX buffer is Ok Are you remember some? And anyway, with new scheme driver developer know requirement of device and will prepare second buffer for that device. Thanks to imp@ we have transfer structure which able to carry that simply :) > > > 2. Do we really need to spend clock cycles on that buffer? > > For AT91 it is required, others maybe not. I'm more about software :) > > > 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) > > They can't otherwise. They(drivers) can fill his(controllers) requirements :) > > > 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 == 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. > > Sounds good. > Static buffers however may require multiple DMA setup if the transfer > request ist bigger. > With AT91 this can be done via *empty interrupt to replay the same buffer. > It is just not wise to interrupt on each single byte, which would be required > without a DMA buffer at all. > Sending 0xff as default dummy data requires filling the TX buffer with > this value, so maybe if doing static then have 2 buffers, one with 0xff > dummy data and one bit-bucket buffer to RX into. > Otherwise use the same dummy data and if a driver requires sending dummy > 0xff it needs to supply its own buffer, but there are many devices requiring > this. Better to not do something special, until we know requirements. Device want zeros on input while it do output, then driver must care for that. Simple is always better :-D > > > 2. teach consumers to give only correct numbers (very nice we have only > > two SPI devices in tree) > > > > 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. > > I don't think there are many devices requiring RX/TX at the same time. Anyway, we will be able to do that, and we don't care now because don't have such drivers yet. > And if a controller won't support it there is nothing to be done anyway > beside bit bang-ing. > But I usually do RX/TX at the same transfer with devices wanting a comand > word and then sending data at the next data word. > In many cases you must not deassert CS during this. As I seen, all controller drivers do exact that. > I don't know how CS is handled in our SPI as I never did SPI with FreeBSD. > If CS is handled automatically on each transaction then it must support > bidirectional transactions. > If CS however are done with separate calls it is Ok to do a TX and then > an TX call before deasserting. > The AT91 hardware has automatic CS support - in my own controller code > outside of FreeBSD I usually prefer handling CS with GPIO for that reason. > > > Hope I'm not forget something important :-D > > > > Thanks to all! > > > > WBW > > -- > > Aleksandr Rybalko > > -- > B.Walter http://www.bwct.de > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. Thanks for comments Bernd! WBW -- Aleksandr Rybalko From owner-freebsd-mips@FreeBSD.ORG Thu Feb 21 15:21:03 2013 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3CF35F67; Thu, 21 Feb 2013 15:21:03 +0000 (UTC) (envelope-from pkelsey@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 556BEC2B; Thu, 21 Feb 2013 15:21:01 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id w5so4181529bku.41 for ; Thu, 21 Feb 2013 07:21:01 -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=s9vmj0Q10HVzEGIuwILtE//1cgLoNE+tOUjr0DgghTU=; b=MIhselwS7Eta5g5m/9Ehi81j3XiC3/ajoDZkVjvD9KsZe4oNYC8g8Lj1iIJRDjjrR5 WVsm+4UhNaCU3KwmngtbI4i3LRrViTwcfmDQfh2YR1AX78xuLhDDqMnp+XenbI/h5JJK jk684f4aSSelStK735t31rXK94aUkkVoAO7wzH2cqsudkMPHpo10rlpTB5qt/hQTzHzu /5es4Xsd4O338s5sXgXgWjoqFBnv4V3iVVVz5hUafnaEXhdXtxvVgMhnl074rKc9hi3f kC6x237t2kaq4rTgMgQkrSiQ10+c43sYXPX28bS5XZfhzqB/7ldZBgU34x6pCrL/tG44 iXnA== MIME-Version: 1.0 X-Received: by 10.204.157.150 with SMTP id b22mr10643610bkx.121.1361460060904; Thu, 21 Feb 2013 07:21:00 -0800 (PST) Sender: pkelsey@gmail.com Received: by 10.204.128.213 with HTTP; Thu, 21 Feb 2013 07:21:00 -0800 (PST) In-Reply-To: <20130221163026.dbeb03f9c38de3d24a7ab30f@freebsd.org> References: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> <20130220174449.GB6976@cicely7.cicely.de> <20130221022655.6f693eb6.ray@freebsd.org> <20130221014433.GA12189@cicely7.cicely.de> <20130221163026.dbeb03f9c38de3d24a7ab30f@freebsd.org> Date: Thu, 21 Feb 2013 10:21:00 -0500 X-Google-Sender-Auth: J65QkwzS-WHCMjsxmJsL8WBBtOE Message-ID: Subject: Re: SPI, _sz fields in struct spi_command From: Patrick Kelsey To: Aleksandr Rybalko Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arm@freebsd.org, Bernd Walter , 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 15:21:03 -0000 >On Thu, Feb 21, 2013 at 9:30 AM, Aleksandr Rybalko wrote: >> On Thu, 21 Feb 2013 02:44:33 +0100 >> Bernd Walter wrote: >> >> On Thu, Feb 21, 2013 at 02:26:55AM +0200, Aleksandr Rybalko wrote: >> > 2. teach consumers to give only correct numbers (very nice we have only >> > two SPI devices in tree) >> > >> > 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. >> >> I don't think there are many devices requiring RX/TX at the same time. > > Anyway, we will be able to do that, and we don't care now because don't > have such drivers yet. > Taking the view that "RX/TX at the same time" means that one wants to send meaningful data to the slave device at the same time one is interested in what data is returned during that transmission, there are such devices in use out there. Linear Technologies has several ADCs, such as the LTC2446, for which you obtain the previous conversion result while sending the configuration bits for the next conversion to be performed. Although this is slightly out of focus for the specific issue originally raised, while on the topic of things that need to get done on SPI in real systems, there are also devices out there that require specific data or some number of clocks to be provided while chip select is deasserted. One example of the former is the LTC2404, which is a multichannel ADC for which the input channel for the next conversion is selected by the last four bits clocked in *before* chip select is asserted. One example of the latter is the spec for SPI access to MMC/SD cards, which requires a certain number of clocks to be applied with chip select deasserted in order to initialize the card. If you ever find yourself wondering why an SPI software interface provides independent bus acquisition and chip select control, the reason is to support these types of devices. -Patrick From owner-freebsd-mips@FreeBSD.ORG Thu Feb 21 16:30:28 2013 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3BBF3377; Thu, 21 Feb 2013 16:30:28 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id DB3282B5; Thu, 21 Feb 2013 16:30:26 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id r1LGUIl2043298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Feb 2013 17:30:18 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id r1LGU4Zp074880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2013 17:30:04 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id r1LGU4Se017045; Thu, 21 Feb 2013 17:30:04 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id r1LGU3xn017044; Thu, 21 Feb 2013 17:30:03 +0100 (CET) (envelope-from ticso) Date: Thu, 21 Feb 2013 17:30:03 +0100 From: Bernd Walter To: Patrick Kelsey Subject: Re: SPI, _sz fields in struct spi_command Message-ID: <20130221163003.GC12189@cicely7.cicely.de> References: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> <20130220174449.GB6976@cicely7.cicely.de> <20130221022655.6f693eb6.ray@freebsd.org> <20130221014433.GA12189@cicely7.cicely.de> <20130221163026.dbeb03f9c38de3d24a7ab30f@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: Aleksandr Rybalko , Bernd Walter , freebsd-arm@freebsd.org, freebsd-mips@freebsd.org, ticso@cicely.de X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 16:30:28 -0000 On Thu, Feb 21, 2013 at 10:21:00AM -0500, Patrick Kelsey wrote: > >On Thu, Feb 21, 2013 at 9:30 AM, Aleksandr Rybalko wrote: > >> On Thu, 21 Feb 2013 02:44:33 +0100 > >> Bernd Walter wrote: > >> > >> On Thu, Feb 21, 2013 at 02:26:55AM +0200, Aleksandr Rybalko wrote: > >> > 2. teach consumers to give only correct numbers (very nice we have only > >> > two SPI devices in tree) > >> > > >> > 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. > >> > >> I don't think there are many devices requiring RX/TX at the same time. > > > > Anyway, we will be able to do that, and we don't care now because don't > > have such drivers yet. > > > > Taking the view that "RX/TX at the same time" means that one wants to > send meaningful data to the slave device at the same time one is > interested in what data is returned during that transmission, there > are such devices in use out there. Linear Technologies has several > ADCs, such as the LTC2446, for which you obtain the previous > conversion result while sending the configuration bits for the next > conversion to be performed. Forgot about ADC with channel selection. > Although this is slightly out of focus for the specific issue > originally raised, while on the topic of things that need to get done > on SPI in real systems, there are also devices out there that require > specific data or some number of clocks to be provided while chip > select is deasserted. One example of the former is the LTC2404, which > is a multichannel ADC for which the input channel for the next > conversion is selected by the last four bits clocked in *before* chip > select is asserted. One example of the latter is the spec for SPI > access to MMC/SD cards, which requires a certain number of clocks to > be applied with chip select deasserted in order to initialize the > card. If you ever find yourself wondering why an SPI software > interface provides independent bus acquisition and chip select > control, the reason is to support these types of devices. With many ADC you also want probing support. Assign CS and GPIO-read MISO for ready without clocking. Some flash chips also work this way. Not sure if AT45DB support this and how our driver works. With own projects I usually ask AT45DB about ready state by transfering a status word. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-mips@FreeBSD.ORG Thu Feb 21 22:02:24 2013 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2CD7EAC6; Thu, 21 Feb 2013 22:02:24 +0000 (UTC) (envelope-from ray@freebsd.org) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id A34FDF46; Thu, 21 Feb 2013 22:02:23 +0000 (UTC) Received: from rnote.ddteam.net (216-44-133-95.pool.ukrtel.net [95.133.44.216]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id 960CFC4930; Fri, 22 Feb 2013 00:02:21 +0200 (EET) Date: Fri, 22 Feb 2013 00:02:07 +0200 From: Aleksandr Rybalko To: ticso@cicely.de Subject: Re: SPI, _sz fields in struct spi_command Message-Id: <20130222000207.d1478231.ray@freebsd.org> In-Reply-To: <20130221163003.GC12189@cicely7.cicely.de> References: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> <20130220174449.GB6976@cicely7.cicely.de> <20130221022655.6f693eb6.ray@freebsd.org> <20130221014433.GA12189@cicely7.cicely.de> <20130221163026.dbeb03f9c38de3d24a7ab30f@freebsd.org> <20130221163003.GC12189@cicely7.cicely.de> Organization: FreeBSD.ORG X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) X-Operating-System: FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, Bernd Walter , 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 22:02:24 -0000 On Thu, 21 Feb 2013 17:30:03 +0100 Bernd Walter wrote: > On Thu, Feb 21, 2013 at 10:21:00AM -0500, Patrick Kelsey wrote: > > >On Thu, Feb 21, 2013 at 9:30 AM, Aleksandr Rybalko > > > wrote: > > >> On Thu, 21 Feb 2013 02:44:33 +0100 > > >> Bernd Walter wrote: > > >> > > >> On Thu, Feb 21, 2013 at 02:26:55AM +0200, Aleksandr Rybalko > > >> wrote: > > >> > 2. teach consumers to give only correct numbers (very nice we > > >> > have only two SPI devices in tree) > > >> > > > >> > 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. > > >> > > >> I don't think there are many devices requiring RX/TX at the same > > >> time. > > > > > > Anyway, we will be able to do that, and we don't care now because > > > don't have such drivers yet. > > > > > > > Taking the view that "RX/TX at the same time" means that one wants > > to send meaningful data to the slave device at the same time one is > > interested in what data is returned during that transmission, there > > are such devices in use out there. Linear Technologies has several > > ADCs, such as the LTC2446, for which you obtain the previous > > conversion result while sending the configuration bits for the next > > conversion to be performed. > > Forgot about ADC with channel selection. > > > Although this is slightly out of focus for the specific issue > > originally raised, while on the topic of things that need to get > > done on SPI in real systems, there are also devices out there that > > require specific data or some number of clocks to be provided while > > chip select is deasserted. One example of the former is the > > LTC2404, which is a multichannel ADC for which the input channel > > for the next conversion is selected by the last four bits clocked > > in *before* chip select is asserted. One example of the latter is > > the spec for SPI access to MMC/SD cards, which requires a certain > > number of clocks to be applied with chip select deasserted in order > > to initialize the card. If you ever find yourself wondering why an > > SPI software interface provides independent bus acquisition and > > chip select control, the reason is to support these types of > > devices. > > With many ADC you also want probing support. > Assign CS and GPIO-read MISO for ready without clocking. > Some flash chips also work this way. > Not sure if AT45DB support this and how our driver works. > With own projects I usually ask AT45DB about ready state by > transfering a status word. > > -- > B.Walter http://www.bwct.de > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. Guys, I don't said it will not be supported. :) I said drivers of controllers who can't will return error in that case, but other might be ok. So, conclusion: go-go-go ray! do it please! :-D -- Aleksandr Rybalko From owner-freebsd-mips@FreeBSD.ORG Thu Feb 21 22:39:50 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 2F82CD4F; Thu, 21 Feb 2013 22:39:50 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 2319F1DA; Thu, 21 Feb 2013 22:39:48 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r1LMdlqr048239; Thu, 21 Feb 2013 15:39:48 -0700 (MST) (envelope-from ian@FreeBSD.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r1LMdj1G053497; Thu, 21 Feb 2013 15:39:45 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: SPI, _sz fields in struct spi_command From: Ian Lepore To: Aleksandr Rybalko In-Reply-To: <20130222000207.d1478231.ray@freebsd.org> References: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> <20130220174449.GB6976@cicely7.cicely.de> <20130221022655.6f693eb6.ray@freebsd.org> <20130221014433.GA12189@cicely7.cicely.de> <20130221163026.dbeb03f9c38de3d24a7ab30f@freebsd.org> <20130221163003.GC12189@cicely7.cicely.de> <20130222000207.d1478231.ray@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Thu, 21 Feb 2013 15:39:45 -0700 Message-ID: <1361486385.1185.38.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org, Bernd Walter , 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 22:39:50 -0000 On Fri, 2013-02-22 at 00:02 +0200, Aleksandr Rybalko wrote: > On Thu, 21 Feb 2013 17:30:03 +0100 > Bernd Walter wrote: > > > On Thu, Feb 21, 2013 at 10:21:00AM -0500, Patrick Kelsey wrote: > > > >On Thu, Feb 21, 2013 at 9:30 AM, Aleksandr Rybalko > > > > wrote: > > > >> On Thu, 21 Feb 2013 02:44:33 +0100 > > > >> Bernd Walter wrote: > > > >> > > > >> On Thu, Feb 21, 2013 at 02:26:55AM +0200, Aleksandr Rybalko > > > >> wrote: > > > >> > 2. teach consumers to give only correct numbers (very nice we > > > >> > have only two SPI devices in tree) > > > >> > > > > >> > 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. > > > >> > > > >> I don't think there are many devices requiring RX/TX at the same > > > >> time. > > > > > > > > Anyway, we will be able to do that, and we don't care now because > > > > don't have such drivers yet. > > > > > > > > > > Taking the view that "RX/TX at the same time" means that one wants > > > to send meaningful data to the slave device at the same time one is > > > interested in what data is returned during that transmission, there > > > are such devices in use out there. Linear Technologies has several > > > ADCs, such as the LTC2446, for which you obtain the previous > > > conversion result while sending the configuration bits for the next > > > conversion to be performed. > > > > Forgot about ADC with channel selection. > > > > > Although this is slightly out of focus for the specific issue > > > originally raised, while on the topic of things that need to get > > > done on SPI in real systems, there are also devices out there that > > > require specific data or some number of clocks to be provided while > > > chip select is deasserted. One example of the former is the > > > LTC2404, which is a multichannel ADC for which the input channel > > > for the next conversion is selected by the last four bits clocked > > > in *before* chip select is asserted. One example of the latter is > > > the spec for SPI access to MMC/SD cards, which requires a certain > > > number of clocks to be applied with chip select deasserted in order > > > to initialize the card. If you ever find yourself wondering why an > > > SPI software interface provides independent bus acquisition and > > > chip select control, the reason is to support these types of > > > devices. > > > > With many ADC you also want probing support. > > Assign CS and GPIO-read MISO for ready without clocking. > > Some flash chips also work this way. > > Not sure if AT45DB support this and how our driver works. > > With own projects I usually ask AT45DB about ready state by > > transfering a status word. > > > > -- > > B.Walter http://www.bwct.de > > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. > > Guys, I don't said it will not be supported. :) > I said drivers of controllers who can't will return error in that case, > but other might be ok. > > So, conclusion: go-go-go ray! do it please! > :-D > One other little thought to consider... since tx and rx size must be the same if they're both non-zero, then could we change to having a single io_size field, and pass a NULL pointer for rx or tx buffer if that part of the transfer isn't needed? -- Ian From owner-freebsd-mips@FreeBSD.ORG Thu Feb 21 22:59:41 2013 Return-Path: Delivered-To: freebsd-mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E1D5D719; Thu, 21 Feb 2013 22:59:41 +0000 (UTC) (envelope-from ray@freebsd.org) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 324D22E6; Thu, 21 Feb 2013 22:59:40 +0000 (UTC) Received: from rnote.ddteam.net (216-44-133-95.pool.ukrtel.net [95.133.44.216]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id CC5C0C493C; Fri, 22 Feb 2013 00:59:39 +0200 (EET) Date: Fri, 22 Feb 2013 00:59:26 +0200 From: Aleksandr Rybalko To: Ian Lepore Subject: Re: SPI, _sz fields in struct spi_command Message-Id: <20130222005926.2aa6db7f.ray@freebsd.org> In-Reply-To: <1361486385.1185.38.camel@revolution.hippie.lan> References: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> <20130220174449.GB6976@cicely7.cicely.de> <20130221022655.6f693eb6.ray@freebsd.org> <20130221014433.GA12189@cicely7.cicely.de> <20130221163026.dbeb03f9c38de3d24a7ab30f@freebsd.org> <20130221163003.GC12189@cicely7.cicely.de> <20130222000207.d1478231.ray@freebsd.org> <1361486385.1185.38.camel@revolution.hippie.lan> Organization: FreeBSD.ORG X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) X-Operating-System: FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Aleksandr Rybalko , Bernd Walter , 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 22:59:42 -0000 On Thu, 21 Feb 2013 15:39:45 -0700 Ian Lepore wrote: > On Fri, 2013-02-22 at 00:02 +0200, Aleksandr Rybalko wrote: > > On Thu, 21 Feb 2013 17:30:03 +0100 > > Bernd Walter wrote: > > > > > On Thu, Feb 21, 2013 at 10:21:00AM -0500, Patrick Kelsey wrote: > > > > >On Thu, Feb 21, 2013 at 9:30 AM, Aleksandr Rybalko > > > > > wrote: > > > > >> On Thu, 21 Feb 2013 02:44:33 +0100 > > > > >> Bernd Walter wrote: > > > > >> > > > > >> On Thu, Feb 21, 2013 at 02:26:55AM +0200, Aleksandr Rybalko > > > > >> wrote: > > > > >> > 2. teach consumers to give only correct numbers (very nice > > > > >> > we have only two SPI devices in tree) > > > > >> > > > > > >> > 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. > > > > >> > > > > >> I don't think there are many devices requiring RX/TX at the > > > > >> same time. > > > > > > > > > > Anyway, we will be able to do that, and we don't care now > > > > > because don't have such drivers yet. > > > > > > > > > > > > > Taking the view that "RX/TX at the same time" means that one > > > > wants to send meaningful data to the slave device at the same > > > > time one is interested in what data is returned during that > > > > transmission, there are such devices in use out there. Linear > > > > Technologies has several ADCs, such as the LTC2446, for which > > > > you obtain the previous conversion result while sending the > > > > configuration bits for the next conversion to be performed. > > > > > > Forgot about ADC with channel selection. > > > > > > > Although this is slightly out of focus for the specific issue > > > > originally raised, while on the topic of things that need to get > > > > done on SPI in real systems, there are also devices out there > > > > that require specific data or some number of clocks to be > > > > provided while chip select is deasserted. One example of the > > > > former is the LTC2404, which is a multichannel ADC for which > > > > the input channel for the next conversion is selected by the > > > > last four bits clocked in *before* chip select is asserted. > > > > One example of the latter is the spec for SPI access to MMC/SD > > > > cards, which requires a certain number of clocks to be applied > > > > with chip select deasserted in order to initialize the card. > > > > If you ever find yourself wondering why an SPI software > > > > interface provides independent bus acquisition and chip select > > > > control, the reason is to support these types of devices. > > > > > > With many ADC you also want probing support. > > > Assign CS and GPIO-read MISO for ready without clocking. > > > Some flash chips also work this way. > > > Not sure if AT45DB support this and how our driver works. > > > With own projects I usually ask AT45DB about ready state by > > > transfering a status word. > > > > > > -- > > > B.Walter http://www.bwct.de > > > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner > > > uvm. > > > > Guys, I don't said it will not be supported. :) > > I said drivers of controllers who can't will return error in that > > case, but other might be ok. > > > > So, conclusion: go-go-go ray! do it please! > > :-D > > > > One other little thought to consider... since tx and rx size must be > the same if they're both non-zero, then could we change to having a > single io_size field, and pass a NULL pointer for rx or tx buffer if > that part of the transfer isn't needed? > > -- Ian > > Yeah, very-very good idea! That how my uncommited driver for i.MX515 SPI works :) Objections? WBW -- Aleksandr Rybalko From owner-freebsd-mips@FreeBSD.ORG Thu Feb 21 23:02:59 2013 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7A42A98E for ; Thu, 21 Feb 2013 23:02:59 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) by mx1.freebsd.org (Postfix) with ESMTP id 3B9F632B for ; Thu, 21 Feb 2013 23:02:59 +0000 (UTC) Received: by mail-yh0-f49.google.com with SMTP id m1so12833yhg.22 for ; Thu, 21 Feb 2013 15:02:58 -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=18hoJwfk6xsq6duaD+G5D0Ouaw0gSr3f7iGliAf0gl4=; b=Dxw5tkvsgszcY31M9OFf459Xmt6zihpycUskSz9zZrDCN8fwCvGqWtJS8GdMsLCRVv 2oS+rxWItaatC6g69jnaBlvTWn979dEhHJEoonwFWHE4cDDS6cToQLU+Do2XWbCOjOGT rwtTjWEO5kiCSHYa9tEkqyUa5uB/r4QNtxftmlZGRhuaegcdEwCo/FNtrtTZO9u4IJhM GWROh86F5EcnXhGCYoR18E7c14F8vxUYqjR5cBP724EZ84fSW7Eg0yuYnlNlzcGVRatx deEB1OJVR789gum2kgsgPaKDG3J5NW3ymJ+bFNNFuyNAp5Cf7El2NyoPXdFUK0YYkXKZ r9KQ== X-Received: by 10.236.139.113 with SMTP id b77mr48035628yhj.130.1361487778466; Thu, 21 Feb 2013 15:02:58 -0800 (PST) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id f20sm288851ang.10.2013.02.21.15.02.56 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Feb 2013 15:02:57 -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: <20130222005926.2aa6db7f.ray@freebsd.org> Date: Thu, 21 Feb 2013 16:02:54 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> <20130220174449.GB6976@cicely7.cicely.de> <20130221022655.6f693eb6.ray@freebsd.org> <20130221014433.GA12189@cicely7.cicely.de> <20130221163026.dbeb03f9c38de3d24a7ab30f@freebsd.org> <20130221163003.GC12189@cicely7.cicely.de> <20130222000207.d1478231.ray@freebsd.org> <1361486385.1185.38.camel@revolution.hippie.lan> <20130222005926.2aa6db7f.ray@freebsd.org> To: Aleksandr Rybalko X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnf+NDIUVJAiTi0Irfp87I4pg9vXDCs575HesRxa6Ri1BMz87gtt32mlrCum3RI04Tu/Ktk Cc: freebsd-arm@FreeBSD.org, Bernd Walter , ticso@cicely.de, Ian Lepore , 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 23:02:59 -0000 On Feb 21, 2013, at 3:59 PM, Aleksandr Rybalko wrote: > On Thu, 21 Feb 2013 15:39:45 -0700 > Ian Lepore wrote: > >> On Fri, 2013-02-22 at 00:02 +0200, Aleksandr Rybalko wrote: >>> On Thu, 21 Feb 2013 17:30:03 +0100 >>> Bernd Walter wrote: >>> >>>> On Thu, Feb 21, 2013 at 10:21:00AM -0500, Patrick Kelsey wrote: >>>>>> On Thu, Feb 21, 2013 at 9:30 AM, Aleksandr Rybalko >>>>>> wrote: >>>>>>> On Thu, 21 Feb 2013 02:44:33 +0100 >>>>>>> Bernd Walter wrote: >>>>>>> >>>>>>> On Thu, Feb 21, 2013 at 02:26:55AM +0200, Aleksandr Rybalko >>>>>>> wrote: >>>>>>>> 2. teach consumers to give only correct numbers (very nice >>>>>>>> we have only two SPI devices in tree) >>>>>>>> >>>>>>>> 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. >>>>>>> >>>>>>> I don't think there are many devices requiring RX/TX at the >>>>>>> same time. >>>>>> >>>>>> Anyway, we will be able to do that, and we don't care now >>>>>> because don't have such drivers yet. >>>>>> >>>>> >>>>> Taking the view that "RX/TX at the same time" means that one >>>>> wants to send meaningful data to the slave device at the same >>>>> time one is interested in what data is returned during that >>>>> transmission, there are such devices in use out there. Linear >>>>> Technologies has several ADCs, such as the LTC2446, for which >>>>> you obtain the previous conversion result while sending the >>>>> configuration bits for the next conversion to be performed. >>>> >>>> Forgot about ADC with channel selection. >>>> >>>>> Although this is slightly out of focus for the specific issue >>>>> originally raised, while on the topic of things that need to get >>>>> done on SPI in real systems, there are also devices out there >>>>> that require specific data or some number of clocks to be >>>>> provided while chip select is deasserted. One example of the >>>>> former is the LTC2404, which is a multichannel ADC for which >>>>> the input channel for the next conversion is selected by the >>>>> last four bits clocked in *before* chip select is asserted. >>>>> One example of the latter is the spec for SPI access to MMC/SD >>>>> cards, which requires a certain number of clocks to be applied >>>>> with chip select deasserted in order to initialize the card. >>>>> If you ever find yourself wondering why an SPI software >>>>> interface provides independent bus acquisition and chip select >>>>> control, the reason is to support these types of devices. >>>> >>>> With many ADC you also want probing support. >>>> Assign CS and GPIO-read MISO for ready without clocking. >>>> Some flash chips also work this way. >>>> Not sure if AT45DB support this and how our driver works. >>>> With own projects I usually ask AT45DB about ready state by >>>> transfering a status word. >>>> >>>> -- >>>> B.Walter http://www.bwct.de >>>> Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner >>>> uvm. >>> >>> Guys, I don't said it will not be supported. :) >>> I said drivers of controllers who can't will return error in that >>> case, but other might be ok. >>> >>> So, conclusion: go-go-go ray! do it please! >>> :-D >>> >> >> One other little thought to consider... since tx and rx size must be >> the same if they're both non-zero, then could we change to having a >> single io_size field, and pass a NULL pointer for rx or tx buffer if >> that part of the transfer isn't needed? >> >> -- Ian >> >> > > Yeah, very-very good idea! That how my uncommited driver for i.MX515 > SPI works :) > > Objections? I'm cool with that. Warner From owner-freebsd-mips@FreeBSD.ORG Thu Feb 21 23:17:59 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 3D88EBFC; Thu, 21 Feb 2013 23:17:59 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id DC38B3D5; Thu, 21 Feb 2013 23:17:58 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r1LNHvBd048729; Thu, 21 Feb 2013 16:17:58 -0700 (MST) (envelope-from ian@FreeBSD.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r1LNHtwl053569; Thu, 21 Feb 2013 16:17:55 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: SPI, _sz fields in struct spi_command From: Ian Lepore To: Aleksandr Rybalko In-Reply-To: <20130222005926.2aa6db7f.ray@freebsd.org> References: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> <20130220174449.GB6976@cicely7.cicely.de> <20130221022655.6f693eb6.ray@freebsd.org> <20130221014433.GA12189@cicely7.cicely.de> <20130221163026.dbeb03f9c38de3d24a7ab30f@freebsd.org> <20130221163003.GC12189@cicely7.cicely.de> <20130222000207.d1478231.ray@freebsd.org> <1361486385.1185.38.camel@revolution.hippie.lan> <20130222005926.2aa6db7f.ray@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Thu, 21 Feb 2013 16:17:55 -0700 Message-ID: <1361488675.1185.42.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org, Bernd Walter , 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 23:17:59 -0000 On Fri, 2013-02-22 at 00:59 +0200, Aleksandr Rybalko wrote: > On Thu, 21 Feb 2013 15:39:45 -0700 > Ian Lepore wrote: > > > On Fri, 2013-02-22 at 00:02 +0200, Aleksandr Rybalko wrote: > > > On Thu, 21 Feb 2013 17:30:03 +0100 > > > Bernd Walter wrote: > > > > > > > On Thu, Feb 21, 2013 at 10:21:00AM -0500, Patrick Kelsey wrote: > > > > > >On Thu, Feb 21, 2013 at 9:30 AM, Aleksandr Rybalko > > > > > > wrote: > > > > > >> On Thu, 21 Feb 2013 02:44:33 +0100 > > > > > >> Bernd Walter wrote: > > > > > >> > > > > > >> On Thu, Feb 21, 2013 at 02:26:55AM +0200, Aleksandr Rybalko > > > > > >> wrote: > > > > > >> > 2. teach consumers to give only correct numbers (very nice > > > > > >> > we have only two SPI devices in tree) > > > > > >> > > > > > > >> > 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. > > > > > >> > > > > > >> I don't think there are many devices requiring RX/TX at the > > > > > >> same time. > > > > > > > > > > > > Anyway, we will be able to do that, and we don't care now > > > > > > because don't have such drivers yet. > > > > > > > > > > > > > > > > Taking the view that "RX/TX at the same time" means that one > > > > > wants to send meaningful data to the slave device at the same > > > > > time one is interested in what data is returned during that > > > > > transmission, there are such devices in use out there. Linear > > > > > Technologies has several ADCs, such as the LTC2446, for which > > > > > you obtain the previous conversion result while sending the > > > > > configuration bits for the next conversion to be performed. > > > > > > > > Forgot about ADC with channel selection. > > > > > > > > > Although this is slightly out of focus for the specific issue > > > > > originally raised, while on the topic of things that need to get > > > > > done on SPI in real systems, there are also devices out there > > > > > that require specific data or some number of clocks to be > > > > > provided while chip select is deasserted. One example of the > > > > > former is the LTC2404, which is a multichannel ADC for which > > > > > the input channel for the next conversion is selected by the > > > > > last four bits clocked in *before* chip select is asserted. > > > > > One example of the latter is the spec for SPI access to MMC/SD > > > > > cards, which requires a certain number of clocks to be applied > > > > > with chip select deasserted in order to initialize the card. > > > > > If you ever find yourself wondering why an SPI software > > > > > interface provides independent bus acquisition and chip select > > > > > control, the reason is to support these types of devices. > > > > > > > > With many ADC you also want probing support. > > > > Assign CS and GPIO-read MISO for ready without clocking. > > > > Some flash chips also work this way. > > > > Not sure if AT45DB support this and how our driver works. > > > > With own projects I usually ask AT45DB about ready state by > > > > transfering a status word. > > > > > > > > -- > > > > B.Walter http://www.bwct.de > > > > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner > > > > uvm. > > > > > > Guys, I don't said it will not be supported. :) > > > I said drivers of controllers who can't will return error in that > > > case, but other might be ok. > > > > > > So, conclusion: go-go-go ray! do it please! > > > :-D > > > > > > > One other little thought to consider... since tx and rx size must be > > the same if they're both non-zero, then could we change to having a > > single io_size field, and pass a NULL pointer for rx or tx buffer if > > that part of the transfer isn't needed? > > > > -- Ian > > > > > > Yeah, very-very good idea! That how my uncommited driver for i.MX515 > SPI works :) > > Objections? > > WBW So just to be clear... if a device driver passes a NULL tx pointer to the controller driver, it's saying "My device doesn't care what it receives during this transfer." If the device needs zeroes or ones then the buffer full of them has to be provided, right? I'm thinking for the controller that does dma, this simplifies things down to making a bus_dmamem_alloc() call (which is fast these days because of the zone allocator) and it doesn't bother to set the contents of that buffer to anything before starting the dma. -- Ian From owner-freebsd-mips@FreeBSD.ORG Fri Feb 22 00:05:34 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 645769D6; Fri, 22 Feb 2013 00:05:34 +0000 (UTC) (envelope-from ray@freebsd.org) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id C311280A; Fri, 22 Feb 2013 00:05:33 +0000 (UTC) Received: from rnote.ddteam.net (216-44-133-95.pool.ukrtel.net [95.133.44.216]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id 352CEC493D; Fri, 22 Feb 2013 02:05:31 +0200 (EET) Date: Fri, 22 Feb 2013 02:05:17 +0200 From: Aleksandr Rybalko To: Ian Lepore Subject: Re: SPI, _sz fields in struct spi_command Message-Id: <20130222020517.f0bd9987.ray@freebsd.org> In-Reply-To: <1361488675.1185.42.camel@revolution.hippie.lan> References: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> <20130220174449.GB6976@cicely7.cicely.de> <20130221022655.6f693eb6.ray@freebsd.org> <20130221014433.GA12189@cicely7.cicely.de> <20130221163026.dbeb03f9c38de3d24a7ab30f@freebsd.org> <20130221163003.GC12189@cicely7.cicely.de> <20130222000207.d1478231.ray@freebsd.org> <1361486385.1185.38.camel@revolution.hippie.lan> <20130222005926.2aa6db7f.ray@freebsd.org> <1361488675.1185.42.camel@revolution.hippie.lan> Organization: FreeBSD.ORG X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) X-Operating-System: FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Aleksandr Rybalko , Bernd Walter , freebsd-arm@FreeBSD.org, freebsd-mips@FreeBSD.org, ticso@cicely.de 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, 22 Feb 2013 00:05:34 -0000 On Thu, 21 Feb 2013 16:17:55 -0700 Ian Lepore wrote: > On Fri, 2013-02-22 at 00:59 +0200, Aleksandr Rybalko wrote: > > On Thu, 21 Feb 2013 15:39:45 -0700 > > Ian Lepore wrote: > > > > > On Fri, 2013-02-22 at 00:02 +0200, Aleksandr Rybalko wrote: > > > > On Thu, 21 Feb 2013 17:30:03 +0100 > > > > Bernd Walter wrote: > > > > > > > > > On Thu, Feb 21, 2013 at 10:21:00AM -0500, Patrick Kelsey > > > > > wrote: > > > > > > >On Thu, Feb 21, 2013 at 9:30 AM, Aleksandr Rybalko > > > > > > > wrote: > > > > > > >> On Thu, 21 Feb 2013 02:44:33 +0100 > > > > > > >> Bernd Walter wrote: > > > > > > >> > > > > > > >> On Thu, Feb 21, 2013 at 02:26:55AM +0200, Aleksandr > > > > > > >> Rybalko wrote: > > > > > > >> > 2. teach consumers to give only correct numbers (very > > > > > > >> > nice we have only two SPI devices in tree) > > > > > > >> > > > > > > > >> > 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. > > > > > > >> > > > > > > >> I don't think there are many devices requiring RX/TX at > > > > > > >> the same time. > > > > > > > > > > > > > > Anyway, we will be able to do that, and we don't care now > > > > > > > because don't have such drivers yet. > > > > > > > > > > > > > > > > > > > Taking the view that "RX/TX at the same time" means that one > > > > > > wants to send meaningful data to the slave device at the > > > > > > same time one is interested in what data is returned during > > > > > > that transmission, there are such devices in use out > > > > > > there. Linear Technologies has several ADCs, such as the > > > > > > LTC2446, for which you obtain the previous conversion > > > > > > result while sending the configuration bits for the next > > > > > > conversion to be performed. > > > > > > > > > > Forgot about ADC with channel selection. > > > > > > > > > > > Although this is slightly out of focus for the specific > > > > > > issue originally raised, while on the topic of things that > > > > > > need to get done on SPI in real systems, there are also > > > > > > devices out there that require specific data or some number > > > > > > of clocks to be provided while chip select is deasserted. > > > > > > One example of the former is the LTC2404, which is a > > > > > > multichannel ADC for which the input channel for the next > > > > > > conversion is selected by the last four bits clocked in > > > > > > *before* chip select is asserted. One example of the latter > > > > > > is the spec for SPI access to MMC/SD cards, which requires > > > > > > a certain number of clocks to be applied with chip select > > > > > > deasserted in order to initialize the card. If you ever > > > > > > find yourself wondering why an SPI software interface > > > > > > provides independent bus acquisition and chip select > > > > > > control, the reason is to support these types of devices. > > > > > > > > > > With many ADC you also want probing support. > > > > > Assign CS and GPIO-read MISO for ready without clocking. > > > > > Some flash chips also work this way. > > > > > Not sure if AT45DB support this and how our driver works. > > > > > With own projects I usually ask AT45DB about ready state by > > > > > transfering a status word. > > > > > > > > > > -- > > > > > B.Walter http://www.bwct.de > > > > > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD > > > > > Rechner uvm. > > > > > > > > Guys, I don't said it will not be supported. :) > > > > I said drivers of controllers who can't will return error in > > > > that case, but other might be ok. > > > > > > > > So, conclusion: go-go-go ray! do it please! > > > > :-D > > > > > > > > > > One other little thought to consider... since tx and rx size must > > > be the same if they're both non-zero, then could we change to > > > having a single io_size field, and pass a NULL pointer for rx or > > > tx buffer if that part of the transfer isn't needed? > > > > > > -- Ian > > > > > > > > > > Yeah, very-very good idea! That how my uncommited driver for i.MX515 > > SPI works :) > > > > Objections? > > > > WBW > > So just to be clear... if a device driver passes a NULL tx pointer to > the controller driver, it's saying "My device doesn't care what it > receives during this transfer." If the device needs zeroes or ones > then the buffer full of them has to be provided, right? One letter will change whole world :-D You said: if (tx == NULL) { drain_rx_to_dev_null(); } cmd_sz - how much to transfer; cmd_tx - TX buffer pointer, or NULL (NULL mean "transmit anything you like or use /etc/master.passwd for that " :) ) cmd_rx - RX buffer pointer, or NULL (NULL mean "I will not read that sucks after transfer, read it if you want" ) Same with data_sz, data_tx, data_rx. > > I'm thinking for the controller that does dma, this simplifies things > down to making a bus_dmamem_alloc() call (which is fast these days > because of the zone allocator) and it doesn't bother to set the > contents of that buffer to anything before starting the dma. Think it will be ok if we alloc one page on start (for those who need it) and then realloc to bigger block if somebody request. > > -- Ian > > Thanks Ian! Thanks Warner! WBW -- Aleksandr Rybalko