From owner-freebsd-embedded@freebsd.org Fri May 27 05:26:22 2016 Return-Path: Delivered-To: freebsd-embedded@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3CE1CB46D42 for ; Fri, 27 May 2016 05:26:22 +0000 (UTC) (envelope-from pkelsey@gmail.com) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E5CC31283; Fri, 27 May 2016 05:26:21 +0000 (UTC) (envelope-from pkelsey@gmail.com) Received: by mail-oi0-x232.google.com with SMTP id k23so158190448oih.0; Thu, 26 May 2016 22:26:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=r+SPifj88k+zBE2PbpTSC3bYc/xN6splD6s5xD2MAkE=; b=pZt9b2y6aK2R1gnqG+lz+9A3ApdsQP4HdKJNAKPVMwRAQJ6vQ3PC2RTGh7vbhnA4Ou KYVxRrPTuxmFvxheKmre1F6D3P3taNlhuGtnzyCkkLF7ZnQoY/A/mEn437GQ44uD1by2 IqosFkIn9QPfxYrF7HigPQEOBEembP/QNPK0gLFUP5JMYldemGQDbZaDen4xfo6syMxP 8+Pbng56czC87AqZW8ZbJa33NMOzk6kHgRDw42s/YfTZL6GJl5vzC9zHJtSdiFH9gd0A tSHoyDZDaIl7V22KuK4OGQ1GiVxJX6Irm7SqOxSCwEmzpHewPacCjQIFv8YOZNaYQX5p 7xTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=r+SPifj88k+zBE2PbpTSC3bYc/xN6splD6s5xD2MAkE=; b=ZKoeFeT0vRbgRb+G88XFEwZHy/hj2Ut57Z1eUq7lnNJHhXa1vGVXqnjC0SsTJTTAEs bQtqbrVBq07+8RD0x8oIzO7xs5lBcqta6Bg4LWaa76v8b6KtPfyRpxKnBo+6x9pgsxg+ Xk0ZXEs39M0pgmSJIufm5lkpEE6Ro02rd6NuFRK4oBBVL/N+mwMhr4wUFNn55r3paIyu fvL96vKd3wF7PWH5JKwoPGuD5RDxUJgzoC0gH3UBPYqzATGYpbrevtnFcao97mriINcL XbZ3fDmnDElTMjb2qV7QwRowp255/CTX+s3VZvEjJDzXom1zRBkHSqQivkPRi0tYchrm dmiw== X-Gm-Message-State: ALyK8tKbnmOgjNOxj6rTd/gr4V4+DyLCAagcLCCIXm2vYoU9/FLbTlAI4m+gNyNAu6aDmkgCI9e9Vdm38HubwA== MIME-Version: 1.0 X-Received: by 10.157.12.178 with SMTP id b47mr8740535otb.6.1464326781149; Thu, 26 May 2016 22:26:21 -0700 (PDT) Sender: pkelsey@gmail.com Received: by 10.157.1.174 with HTTP; Thu, 26 May 2016 22:26:21 -0700 (PDT) In-Reply-To: References: Date: Fri, 27 May 2016 01:26:21 -0400 X-Google-Sender-Auth: T-SRwAxLQ6RjNziIs1CcgOZQF-M Message-ID: Subject: Re: spibus: migrate to bus acquire/release semantics From: Patrick Kelsey To: Adrian Chadd Cc: "freebsd-embedded@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 05:26:22 -0000 On Thu, May 26, 2016 at 10:00 PM, Adrian Chadd wrote: > hi, > > Here's the first part of the work needed to bring mmcspi into the > tree. It also fixes concurrent SPI controller accesses for a variety > of controllers which currently don't consistently implement it - > AR71xx spi doesn't, but brcm2835 spi does. > > https://reviews.freebsd.org/D6588 > > I'd appreciate some feedback and testing. > > Now, this doesn't implement it for all of the controllers, only the > simple ones. The broadcom and other arm ones aren't migrated, because > CS is asserted in a variety of different ways there. Now, it's not a > /huge/ deal, it just means that CS isn't asserted for the entirety of > a transaction set. For mmcspi (which I think assumes this is the > case), we may have to add a controller ivar that indicates if it > supports it or not, so mmcspi and other devices can implement it > appropriately. > > Another good example of this would be an LCD controller. Ideally you'd do > this: > > * acquire SPI bus > * assert command line > * do SPI transaction, with CS asserted > * deassert command line, assert data line > * do SPI transaction, with CS asserted > * release SPI bus > > Now, CS doesn't have to be asserted between transactions, but the > command/data commands have to happen together like that. > > Thanks! > > Thanks for continuing to work on this. One thing mmcspi requires is the ability to control chip select state on a per-SPI-transfer basis, because correct initialization requires providing at least 74 clocks to the device with both CS and MOSI set to high. That means initialization requires: acquire bus clock out enough 0xff with CS high to meet the requirement release bus The mmcspi driver is written so that CS will remain asserted across however many individual SPI-transfers it takes to execute a given MMC/SD command. It is not entirely clear whether this is required. I only had access to the simplified spec, which omits SPI timing diagrams found in the full spec, and possibly further related discussion. Based on the range of goofy behaviors I observed in the set of cards I tested with, I was motivated to be conservative with the treatment of CS during MMC/SD command execution. If it is the case that holding CS asserted during the entire MMC/SD command execution is truly required in some or all cases, then if the underlying SPI controller doesn't support that, I don't think there is anything the mmcspi driver can do other than print a warning. Aside from whether holding CS asserted across all of the individual transfers that the mmcspi driver issues during execution of a single MMC/SD command is truly required, I think this is a useful level of control to have in the interface. There are certainly SPI devices out there that do specific things on low-to-high transitions of CS and thus can require such care. One example is the LTC2440 analog-to-digital converter, which will exit serial-data-out mode and start a new conversion on a low-to-high CS transition. It also so happens that with this device, you detect end-of-conversion by checking the first bit clocked out of it. This encourages a driver implementation that does an 8-bit read to check end of conversion (for bus efficiency), then reads the remaining 24 bits if the end of conversion flag is set in the initial 8 bits retrieved. If CS can't be held high across the final 8-bit poll read and subsequent 24-bit rest-of-result read, the device will change modes and the conversion data will be lost. Without CS control across transactions, the fallback would be for completion polling to take 4 times as long as it needs to as 32-bit reads would always have to be used. -Patrick