From owner-freebsd-current@FreeBSD.ORG Mon Oct 17 17:15:06 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 748751065674 for ; Mon, 17 Oct 2011 17:15:06 +0000 (UTC) (envelope-from ray@ddteam.net) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0C3D48FC18 for ; Mon, 17 Oct 2011 17:15:05 +0000 (UTC) Received: by eyd10 with SMTP id 10so4199276eyd.13 for ; Mon, 17 Oct 2011 10:15:05 -0700 (PDT) Received: by 10.14.18.94 with SMTP id k70mr1337095eek.203.1318870193666; Mon, 17 Oct 2011 09:49:53 -0700 (PDT) Received: from rnote.ddteam.net (167-94-133-95.pool.ukrtel.net. [95.133.94.167]) by mx.google.com with ESMTPS id w58sm31002176eeb.4.2011.10.17.09.49.51 (version=SSLv3 cipher=OTHER); Mon, 17 Oct 2011 09:49:51 -0700 (PDT) Date: Mon, 17 Oct 2011 19:49:40 +0300 From: Aleksandr Rybalko To: current@freebsd.org Message-Id: <20111017194940.ed720115.ray@ddteam.net> X-Mailer: Sylpheed 3.1.0 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: SPI rework X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 17:15:06 -0000 Hi all! I implement new SPI controller driver (for RT305XF) and found interest problem: our current SPI implementation based on transfer data in structure spi_command: struct spi_command { void *tx_cmd; uint32_t tx_cmd_sz; void *rx_cmd; uint32_t rx_cmd_sz; void *tx_data; uint32_t tx_data_sz; void *rx_data; uint32_t rx_data_sz; }; There is the problem 1, because all SPI requests I know use only two transaction parts: 1 - write command (or read command if SPI slave) 2 - read/write device data so something like: { void *cmd; size_t cmd_sz; uint32_t cmd_flags; #define SPI_DIRECTION_READ (0<<0) #define SPI_DIRECTION_WRITE (1<<0) void *data; size_t data_sz; uint32_t data_flags; }; will be more accurate. And the problem number 2: most controllers verify tx_cmd_sz == rx_cmd_sz, so seems `cmd` part must contain only request, and `data` must contain only payload. And the problem number 3: SPI flash driver for example: set buf[0] = 0x9f; /* SPI flash identify query */ then tx_cmd = buf; tx_cmd_sz = rx_cmd_sz = 4; And expect to receive device id in buf[1], buf[2], buf[3]. Soooo, how controller will decide which part of `buf` is a command, and which part is a data? And again which part should be to write, which to read? Somebody maybe ask me: Why you need it? Answer: because RT305XF spi controller can't do bidirectional transfer, that controller can only write or read. Currently we have spi controllers for arm/at91 and mips/atheros (I have also GPIO spi controller) and only one consumer for spibus - dev/flash I "swear" to take care about mips/atheros, dev/flash and dev/spibus, but seems will need some help from someone who work with Atmel's. It will be very nice to have it discussed and done before 9.0. Will wait for any comments and suggestions. WBW -- Aleksandr Rybalko