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=