From owner-freebsd-embedded@freebsd.org Fri May 27 02:00:49 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 90CA7B4AE0B for ; Fri, 27 May 2016 02:00:49 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 5E82617DC for ; Fri, 27 May 2016 02:00:49 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-it0-x234.google.com with SMTP id l63so64902477ita.1 for ; Thu, 26 May 2016 19:00:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to; bh=P7Q+BSsQbIHyiuFBNDXlM/Z/V4Rn+mrkW9TZyyOpOo0=; b=SijqJHq5BRzteB9WmeGERlQqCniMKYW+drKJzVZ39rbwJhHftOyV66Q58tyes9Fe3B sHWmajCRJBk03VK8ZnG0PktrJ6424hUqB1xbwOeiPvDAsEtJgnwO6TZl5lw2eGyKuzwv hCubHovpWgAhtXhg8dtpBgqDUX2+PoDB87odtX4b8//P5FkRyCP/LrjI+ByRs8OmUnjd 1bEzui/rPbKoGhLz9ZeLJgFWYQ6ybDdiry0nPC/Ytuc7BRfe0v9RdxLNZrxY1p6QDO/U ew/LSA7aYSsC3ROqTL8QzJD/Oa1PqBjniPPRSBMNrtOnARvuRqpR8DnkLaG1pBjLQF78 dPbw== 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:date:message-id:subject:from :to; bh=P7Q+BSsQbIHyiuFBNDXlM/Z/V4Rn+mrkW9TZyyOpOo0=; b=lruJZQGWm0i5+uLwFKGFZomsg4OsdY3P3mxME3ILXFscWtlO3KPyHTfgUPD/ycqykt u0TJM5bu8kvOInz/MaMWRGu7secobaII2Uf8UbY9Y/fkCMVmTsJmHtQ76cAwAW7L0sYF mOqHiERNycK0EimLVNHe7hTBUnXPYVAPoMhLIxGLJZafGWboYTxZPxeRyHEAnXBq9sxW XUPfb1tx7H4k4vEAGBiE+WiUmXWrNN0/YQZ4B/aUeJjQQaT20B5voctRGjQ+ogBr+Hvq SWvgLEgMeOmKbb0I1rVKiq+lRLJTyUPwPs0IZvU/ygCej0lA2i/bWhiOOPXN/MZN1Z+w 5tIA== X-Gm-Message-State: ALyK8tI8oy7P9FkN5mwCc4D63c8FgGpr78n0EQnXCdpsZlUgV7bLjFPDVzEdHnEkJLkY1o1lOs4S/aa7DTLy0A== MIME-Version: 1.0 X-Received: by 10.36.73.146 with SMTP id e18mr5556126itd.80.1464314448592; Thu, 26 May 2016 19:00:48 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.113.3 with HTTP; Thu, 26 May 2016 19:00:48 -0700 (PDT) Date: Thu, 26 May 2016 19:00:48 -0700 X-Google-Sender-Auth: UttxX-4BM-rTd8rC22t_g4OTvEI Message-ID: Subject: spibus: migrate to bus acquire/release semantics From: Adrian Chadd To: "freebsd-embedded@freebsd.org" Content-Type: text/plain; charset=UTF-8 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 02:00:49 -0000 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! -adrian 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 From owner-freebsd-embedded@freebsd.org Fri May 27 15:50:18 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 935D0B4C823 for ; Fri, 27 May 2016 15:50:18 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (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 4E3C01139; Fri, 27 May 2016 15:50:18 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x236.google.com with SMTP id f8so74431844ioe.3; Fri, 27 May 2016 08:50:18 -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=SUTC3c1nCGqC5ei15wCSlRMTZz4V2xX9kLkzwPdP36o=; b=mUUFyQoJutb1gMzQyPiTAwI9QMRU3mHyvCKamJk8tSz9PBOflqcRlC39milSAxNJ60 MIqfVxpBXGTXycpjSIbwEg5FGqwkdV6SMerAdjqGIOp8ZEsuNjJV6+kHd2GzIFcK6Wpk uDxh4EupM6pTkqm9QNC+qRh9A41kfOqy+oMUYE4cN4LoXOZY0pUlUYXUBKV/1bmO/iKS CrzIGQ90+JrpK1SeDjEPicsC0v7rKobhhC1aF2UGMKgmRY6mJfT+HiiVi4hbT15M99n4 v6RMn4ROJD9ax/yuzwqReprMH2M4QtW6bhofhv4ovbG8WOrG3dAYByu786JAZ2XOwdrA XY8w== 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=SUTC3c1nCGqC5ei15wCSlRMTZz4V2xX9kLkzwPdP36o=; b=WTUpJICQpIiPtxGiMNiKUJk8zpat8oniSqVbxJJWBybd0QvY1zeU1f4cvMLe4a/0lX +AUuSdBc4ItEbQ6cGsPCxdOyK4/vsTItZCmfs6UfItXUUy9F4TqjrAM2RRLSlFGx5aDr l9LFwaX1aYlViuAODVAhtWEdwBpps6+BENbH2fWtwF+FJIM5FT7LNk/p6UfB8wmf8um/ DO7HE3DH4/L60tdFJppJ+WPKQdEupL1pz0sR357eYcXAiKOoHBTWC+zQTMprGg15iDyp A6mCoOW7iHfOeHhS5rMNRqGlQifR7noWFjbxr/yrxEOvI4tzo71Wgg4P89jX1mDiq8/c H3rQ== X-Gm-Message-State: ALyK8tK8VflwpFDx7HyzIpxiBUOYCDmsypbTivpJCfzFBynpI8U0f1bFFB6jmWzBDf9FKwVhXJNDxKNVaF764Q== MIME-Version: 1.0 X-Received: by 10.107.144.67 with SMTP id s64mr11064394iod.165.1464364217490; Fri, 27 May 2016 08:50:17 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.113.3 with HTTP; Fri, 27 May 2016 08:50:17 -0700 (PDT) In-Reply-To: References: Date: Fri, 27 May 2016 08:50:17 -0700 X-Google-Sender-Auth: NRdm_GQ7V8Un-3Nwwt82ijsU8T4 Message-ID: Subject: Re: spibus: migrate to bus acquire/release semantics From: Adrian Chadd To: Patrick Kelsey Cc: "freebsd-embedded@freebsd.org" Content-Type: text/plain; charset=UTF-8 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 15:50:18 -0000 On 26 May 2016 at 22:26, Patrick Kelsey wrote: > > > 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. Hi, Right. I think warner mentioned something about devices that wanted and devices that didn't want this kind of behaviour. Ian has suggested that we implement it as a per-acquire flag, so the SPI user can determine how they'd like to do things. I'd like to do that after doing the initial conversion, and then likely after I implement some ivars that expose spibus capabilities. So, my (vague) plan is to get this patchset into -HEAD, as it's one enormous API churn that should be a no-op with the current users, and then add ivars for the bus capabilities so things like mmcspi can decide whether they're going to get what they need out of it, and then start porting more of the mmcspi patchset. What hardware were you testing on? I have some mmcspi hardware here, but I'd rather first verify that this works on the original hardware for this project before trying to adapt it to work on the $10 AR9331 part I have.. Thanks! -adrian From owner-freebsd-embedded@freebsd.org Fri May 27 15:52: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 3E7CCB4C966 for ; Fri, 27 May 2016 15:52:22 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (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 09FE213E4; Fri, 27 May 2016 15:52:22 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-ig0-x235.google.com with SMTP id ct2so22280630igb.0; Fri, 27 May 2016 08:52:22 -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=Br/JNUq5B4AKieOgdHMRDNivNOIYFxD6xeSE1hHhcDg=; b=eB/iMQG0fYadIpJDSaoCzL7sCpb8WUGiuS7M8BeOu9FR7syGXSFaO7ALM7CxAUJ9YI NTekeSTp1REa7OsbtTxnusJJjtJKarqRD2OpfLYJaerR6KQ0zWkYVIoqFvHs3l2S2sZr uBLBQkHkdK0x4vPD43kbZTDqJsGdm1iFdsiDvZ/icBvbAMvaRUb030pyPlpNWLq1FHVq iQWyBn6q4AJr3IHe3v5lMwN5HN7lYBSHXSrjlAuFNvdNnthPYcmN7VDzqPPBnmuZ4C9O Fh3EGuDt41IOul4HXj1o7FM/7zUUut0bpkedgL6EcMUqh4UpNUnSXj1+hhgum5KrkEC1 C/qg== 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=Br/JNUq5B4AKieOgdHMRDNivNOIYFxD6xeSE1hHhcDg=; b=cQgttvh4XOf9PCVcrzERk3KZ09ssQaS5+Wkumfb/6NWkZv+Xo4QDH2uR9nnoYBNEXy reR4uw2CHlz19Mf2Z78MP8lo1B2mSurXMyVsaAsoPN352FRd7uVtJLC1Uh5Tt6HP1lwv am4YNxmge14zjImKaLbhqwKslvNWtwI1f70zAqLG2LclxIPHLgfz1sY+jCtQXtF4WinB 2ykLMVL5lTmNHshfm9WUcYvxm7kBjbvViYA7whUdFJDvpXGvOiprfTtK7ij8JR1SeDbv gFJn9zjuyfw7svwj2eEqW5/7nOBjbPsJn6Nsg9+GUSmxYOb/7miqDV84YJGWNB/tA064 Tqpg== X-Gm-Message-State: ALyK8tKBrKPyitkkFGaXaRiV8nF/G/aFW/K/bh2kQSHGXVCGPbpgswd8Ld0cSdBDQDX0/6ArrHaqVR0t94Q1Mw== MIME-Version: 1.0 X-Received: by 10.50.29.15 with SMTP id f15mr8995677igh.37.1464364340331; Fri, 27 May 2016 08:52:20 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.113.3 with HTTP; Fri, 27 May 2016 08:52:20 -0700 (PDT) In-Reply-To: References: Date: Fri, 27 May 2016 08:52:20 -0700 X-Google-Sender-Auth: jdlaHlx8FgZCQ7TzuJjBdFTUReY Message-ID: Subject: Re: spibus: migrate to bus acquire/release semantics From: Adrian Chadd To: Patrick Kelsey Cc: "freebsd-embedded@freebsd.org" Content-Type: text/plain; charset=UTF-8 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 15:52:22 -0000 [snip] There's also the beginnings of a clock API in spibus too, so hopefully we can flesh it out enough to add clock set/get methods so mmcspi (and others!) can do per-bus clock configuration to meet timing requirements. -adrian