From owner-freebsd-embedded@freebsd.org Sun Aug 23 00:17:28 2015 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 7A55E9C0B0F for ; Sun, 23 Aug 2015 00:17:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 52CAFE1C for ; Sun, 23 Aug 2015 00:17:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 4F73F9C0B0E; Sun, 23 Aug 2015 00:17:28 +0000 (UTC) Delivered-To: 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 341269C0B0D for ; Sun, 23 Aug 2015 00:17:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk0-f180.google.com (mail-qk0-f180.google.com [209.85.220.180]) (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 DF4F1E1A for ; Sun, 23 Aug 2015 00:17:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by qkch123 with SMTP id h123so43520806qkc.0 for ; Sat, 22 Aug 2015 17:17:21 -0700 (PDT) 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:content-type; bh=FrXFNM+xMV4kxeoh539sIoFzV7fYDLyg4HFx5JIbJNg=; b=VyrmlSazee39mVYiqYYbjJR03OqOL+Fp7IptpyfaXpQcJ0FaWXdfGOnaXAHUx3cq94 NUFUOnvlCxai8tHt+kLZCaZ1NPx3J4+L+8izvtslyVsu8iI23rGjbiMwuj1w4fB9kFlK ZFkIldqUeiQPC0A8kVKd/x875j606h6ZjaZhPvw00T7E0aInPNv2xkMMo7W/2v6vwSc7 3Ybylfu0wAC9XEzr3LH9XO/w9SahSNEN3kZdob+OvkastefGysYzqMjW9qbd9EQzgi5C MJclgEG7e2GuoBJmHnFZE1ry4A4r6fITr5HENbHCpz+zu4VJGNxqhNajPZ5Lgsod5A+1 TFqA== X-Gm-Message-State: ALoCoQkJKtaxE5Gp0ZrzCnAVWc+4NHm+cT3i2fXJGvibbb6/G0ELj9ODoDV+VraWvVvgopE8A7ag MIME-Version: 1.0 X-Received: by 10.55.25.158 with SMTP id 30mr31813704qkz.40.1440289040886; Sat, 22 Aug 2015 17:17:20 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.140.91.52 with HTTP; Sat, 22 Aug 2015 17:17:20 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: References: <20150817160423.GB3078@gmail.com> Date: Sat, 22 Aug 2015 18:17:20 -0600 X-Google-Sender-Auth: 7VhhbMPUkHXoBT5cWb-IVEw0cuA Message-ID: Subject: Re: spigen(4) SPI Generic IO interface -- need comments From: Warner Losh To: Brian Fundakowski Feldman Cc: Adrian Chadd , Luiz Otavio O Souza , "freebsd-embedded@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Aug 2015 00:17:28 -0000 I've worked on one set of flash that had simple commands for identifying it, which were clocked at one rate (slow, to be compatible with older members of the family), and other commands that were data transfer that were clocked faster to match the data coming from internal pipelines in the part. I don't know how common this arrangement is in the wild, though. And all of this is from memory of something I worked on maybe 10 years ago now, so I'm not sure how relevant it is today. I do know NAND flash chips have similar behavior, but those don't have a SPI bus. Warner On Sat, Aug 22, 2015 at 6:09 PM, Brian Fundakowski Feldman < brianfundakowskifeldman@gmail.com> wrote: > That's something I want feedback on: are there scenarios where you want to > regularly vary the clock to a specific SPI device, as opposed to varying it > among several? It would be easy to add to the transfer ioctls if you have a > use case (for example, manual chip select control with more devices than > chip select pins in your low-level SPI implementation.) Certainly from a > runtime cost perspective it would be no burden. > > Thanks for taking a look! > -- > green > > On Sat, Aug 22, 2015, 5:55 PM Adrian Chadd wrote: > > > Hi! > > > > This looks cool! Is there any reason why the clock isn't per transaction? > > > > > > -a > > > > > > On 22 August 2015 at 11:23, Brian Fundakowski Feldman > > wrote: > > > I've added a couple more features: > > > * clock adjustment via ioctl, independent per spigenN device > > > * mmap(2) support for very low latency > > > > > > On Tue, Aug 18, 2015 at 6:47 PM, Brian Fundakowski Feldman < > > > brianfundakowskifeldman@gmail.com> wrote: > > > > > >> On Mon, Aug 17, 2015 at 12:04 PM Tom Jones wrote: > > >> > > >>> On Mon, Aug 17, 2015 at 10:00:26AM -0400, Brian Fundakowski Feldman > > wrote: > > >>> > I'm woefully out-of-practice with my kernel hackery (but still > pretty > > >>> > proficient in jiggery-pokery) so I would like to get comments on a > > >>> little > > >>> > driver I just made for interfacing arbitrarily in userland with SPI > > >>> > components. The only thing I'm exposing is a /dev/spigenN node > with > > a > > >>> > single transfer ioctl and I put together a test circuit and program > > >>> with an > > >>> > MCP3008 10-bit ADC IC to validate that it basically works, other > than > > >>> the > > >>> > limitation that the transfers must be octet-multiply-sized, but I > > >>> haven't > > >>> > looked at the SoC's (I'm using a Raspberry Pi 2) data sheet to tell > > >>> whether > > >>> > that's just a limit on the spibus(4) interface or the Broadcom SPI > > >>> driver > > >>> > or the Broadcom SoC itself. > > >>> > > > >>> > I hit one snag in development where I simply called the ioctl wrong > > and > > >>> > found copyin(9) to page fault HARD if given a bogus user address to > > copy > > >>> > from, and panic the kernel. I can post up the test program if > anyone > > >>> wants > > >>> > but it's very trivial: I just align the start bit and the command > > data > > >>> into > > >>> > the least significant bits of the first octet, shift it up two > > >>> positions so > > >>> > the NULs get clocked out as part of the command field, and provide > > two > > >>> > octets for the data field to retrieve back the 10-bit digital > value. > > >>> > > >>> Oh, cool. > > >>> > > >>> I did the same earlier this year, have you seen[1]?. > > >>> > > >>> The FreeBSD i2c api is the same/very similar the linux one[2][3]. > Have > > you > > >>> considered adding some of the ioctls[3] or the data structures to > make > > it > > >>> easier to port code? > > >>> > > >>> [1]: > > >>> > > > https://lists.freebsd.org/pipermail/freebsd-embedded/2015-April/002466.html > > >>> [2]: https://www.kernel.org/doc/Documentation/i2c/dev-interface > > >>> [3]: > > >>> > > > https://www.freebsd.org/cgi/man.cgi?query=iic&apropos=0&sektion=0&manpath=FreeBSD+10.2-RELEASE&arch=default&format=html > > >>> [4]: https://www.kernel.org/doc/Documentation/spi/spidev > > >> > > >> > > >> I've iterated a bit on this to try to make some more sensible API, > > >> behaving reasonably about being able to set the SPI clock speed. I'm > > going > > >> to implement an mmap handler so I can have my low-latency operation > > mode, > > >> as well. I don't like the Linux APIs one bit because it's just not > > safe to > > >> allow all those configuration changes on a per-transfer basis... > > >> > > >> Moving this to -embedded because it's more apt than -hackers. > > >> > > > > > > _______________________________________________ > > > freebsd-embedded@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-embedded > > > To unsubscribe, send any mail to " > > freebsd-embedded-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-embedded@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-embedded > To unsubscribe, send any mail to "freebsd-embedded-unsubscribe@freebsd.org > " >