From owner-freebsd-arch@FreeBSD.ORG Sun Sep 2 19:38:10 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A883106566B for ; Sun, 2 Sep 2012 19:38:10 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id 585268FC14 for ; Sun, 2 Sep 2012 19:38:10 +0000 (UTC) Received: by iebc12 with SMTP id c12so3707876ieb.13 for ; Sun, 02 Sep 2012 12:38:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=v0kmt/IO7bJy3i/ZW3aVFrQBCIf9b3USDxId7Nc/e0c=; b=bvMLU51/6ngb92wPH5OmBjhxiDs4jgtCGpNwX6JWECYFKKS9zpjcrvjUZhgFEKSMTZ jCLgeGdNlxYsBMMP7bQCQp9mermfPxfojEaVBx3V0jJ2xh5fVCUvdH3tYGWZZa6748mM H+2YCLqB8xQ68fVkNNlpsWj2hcvIML1DCdswnzP9cSF4L7DrjvsFHlwyK96heq9s84Hv H1bPXjZf47fT3eXj6tjxf5aBx/0nfeBysf879uzax1Fpvj3A+4sbXnzvBjZAX9xGZdtm alINF+lvL1RKk05v0BivxPHrbahnCfzLYxq3Jf/k7kv90AQXGEyNqjmIwXb/9QTQPHST LzNA== Received: by 10.50.220.169 with SMTP id px9mr8692202igc.8.1346614689524; Sun, 02 Sep 2012 12:38:09 -0700 (PDT) Received: from 63.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id fu4sm7010600igc.4.2012.09.02.12.38.07 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 02 Sep 2012 12:38:08 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1346602529.1140.563.camel@revolution.hippie.lan> Date: Sun, 2 Sep 2012 13:38:06 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <3C91462E-1423-4AFC-B4C7-6239E698A98E@bsdimp.com> References: <1346602529.1140.563.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQnBoRfzEsr/qqwwroNwtjldahj1MfqrJ/HBjRdGLWxCGR5+f+DxtLRIVcfQrARWRA7ZwahN Cc: freebsd-arch@freebsd.org, Luiz Otavio O Souza Subject: Re: spibus access serialization X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2012 19:38:10 -0000 On Sep 2, 2012, at 10:15 AM, Ian Lepore wrote: > On Sun, 2012-09-02 at 08:47 -0600, Warner Losh wrote: >> On Sep 2, 2012, at 6:37 AM, Luiz Otavio O Souza wrote: >>=20 >>> Hi, >>>=20 >>> I've some embedded systems with spi devices that share the same = spibus and because of that i'm working to get some kind of access = serialization on spibus and also protection to devices which need a = series of spi transfers to achieve some goal. >>>=20 >>> The SPI usage (with all the patches applied) goes like this: >>>=20 >>> /* Wait until the spibus is free. When free, acquire the bus and = select the device */ >>> SPIBUS_ACQUIRE_BUS(spibus, device); >>=20 >> Does it do this with a sleep? >>=20 >>> /* Program the CPLD to read data from NAND */ >>> SPIBUS_TRANSFER(spibus, device, &cmd); >>>=20 >>> /* Read 'n' bytes from CPLD */ >>> SPIBUS_TRANSFER(spibus, device, &cmd); >>>=20 >>> /* Release the spibus and deselect the device */ >>> SPIBUS_RELEASE_BUS(spibus, device); >>>=20 >>> While today everything is done inside SPIBUS_TRANSFER(). >>>=20 >>> The patch spibus-01.diff adds the bus methods and the default = methods. >>>=20 >>> The spibus-02-devices.diff adds the needed glue to all spi devices = (dev/flash/at45d.c, dev/flash/mx25l.c, arm/lpc/ssd1289.c, = mips/atheros/pcf2123_rtc.c). As the default methods are just nops, there = are no functional changes. >>>=20 >>> On spibus-03-controllers.diff we finally add the serialization = methods to spi controllers (mips/atheros/ar71xx_spi.c and = arm/lpc/lpc_spi.c) and change the device CS to happen on bus acquire and = release and not on start and end of each transfer. >>>=20 >>> The spi controller on arm/at91/at91_spi.c wasn't changed because = looks like it will be need to move the device CS control from the = controller and use it as a GPIO pin. I need to read more of at91 code = before i can suggest some change there. Until there it will work just as = now (no serialization and selecting/deselecting the device within each = transfer). >>=20 >> The at91_spi controller controls which CS line is asserted. So long = as you don't change the bits in the registers, it will stay asserted. I = think it can fit with this scheme. I'll have to take a closer look. = All my AT91 devices have only one chip on the spi bus. >=20 > Unfortunately, the atmel SPI controller will de-assert the chip select > when the transmit register (or PDC) runs out of data. It's a bug that > may only affect rm9200; I haven't checked the errata and docs for the > sam9 series to see if they fixed it. Yes, that's been fixed (which is why I didn't think it would be a = problem, but it is). > The way to fix the problem is indeed to take over the handling of chip > selects in the driver, by taking the pins away from the device and > managing them as GPIOs. Doing that is on my to-do list, but I've been > waiting for some resolution of the "how do we manage device/gpio pin > setup across the atmel SoC family" questions. That's the question still, alas. I've been looking at how FDT does it = in Linux land, and they punt on this issue. We'll likely have to put = some effort into defining these things with atmel's FDT efforts. Their = FDT comes close by defining groups, but doesn't seem to take it down to = the individual pin to signal mapping. Otherwise we'll have to fall back to arrays of pins that somehow get = associated with the device... > This auto-deassert in rm9200 is also the bug that causes us to run the > SPI bus at roughly 1/20th of its rated speed, to ensure that we never > get a spurios chip de-select in the middle of a transfer due to > momentary PDC bus starvation. Yes. The SAM9 processors have a new bit, CSAAT, which forces the line = to be asserted until you deassert it, not just during data transfers. A = quick grep of the code indicates that we don't use it, but I haven't = checked in detail... > Speaking of SPI bus speed, that's the other wart in our SPI support. = We > need a speed limit member in the spi request structure, so that = drivers > of individual devices on the bus can indicate the limit for their > specific devices. I'd be happy to see that get added sooner rather = than > later, even if it takes a while to get all the low-level drivers > supporting it. I think the new field in the struct should indicate = the > fastest speed in Hz that the device can handle the bus running, with > zero meaning no limit. Yes. And SPI mode too. These items should be programmed when the bus = is requested, imho, but perhaps there's a reason not to do this. Warner=