From owner-freebsd-embedded@freebsd.org Sun Aug 23 00:09:36 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 E94819C0986 for ; Sun, 23 Aug 2015 00:09:35 +0000 (UTC) (envelope-from brianfundakowskifeldman@gmail.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 C6777AFB for ; Sun, 23 Aug 2015 00:09:35 +0000 (UTC) (envelope-from brianfundakowskifeldman@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id C32859C0985; Sun, 23 Aug 2015 00:09:35 +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 A7C1B9C0984 for ; Sun, 23 Aug 2015 00:09:35 +0000 (UTC) (envelope-from brianfundakowskifeldman@gmail.com) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (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 69941AF9; Sun, 23 Aug 2015 00:09:35 +0000 (UTC) (envelope-from brianfundakowskifeldman@gmail.com) Received: by igui7 with SMTP id i7so35576118igu.0; Sat, 22 Aug 2015 17:09:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=Lc4d3tAbZfzj/owXxlxafKmuBA4JdLm2AIzLURifDmU=; b=Tp/Gf55G7wWA4m1T3/xAbeNvdLEIngSNOCj7jgIealowPD00wx0HLvNbsWYoImgrDh 3RYqk1xBwPxWE0Z1Lon+PvxgdubDBaRAqsWP/Kqck7xPCQiHdMg6AK3QVWk1OMx9YObh 8n1bbsC7YkdNhaodgr5NgkI7HKhuxcIJvuVn8vCOc5z9NxkxraFjwlV2CgR4zaB3uNFX JjGZqb3WA1g4X2ud6YcbBDMxmy1Z5RCfFQ31ucmt5DyNBkR2KfcYnGxyu53NVnSw49qC VBqn3u5/5cgsL2cVBcr9NzudqyViukcvL5d3+2bjO0H1mlmtQRdn1kf+RxDHIRInSmgQ ZBLg== X-Received: by 10.50.43.169 with SMTP id x9mr3537402igl.7.1440288574467; Sat, 22 Aug 2015 17:09:34 -0700 (PDT) MIME-Version: 1.0 References: <20150817160423.GB3078@gmail.com> In-Reply-To: From: Brian Fundakowski Feldman Date: Sun, 23 Aug 2015 00:09:25 +0000 Message-ID: Subject: Re: spigen(4) SPI Generic IO interface -- need comments To: Adrian Chadd Cc: Tom Jones , 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:09:36 -0000 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" > 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 > " > From owner-freebsd-embedded@freebsd.org Sun Aug 23 00:28:01 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 7560F9C0CB2 for ; Sun, 23 Aug 2015 00:28:01 +0000 (UTC) (envelope-from brianfundakowskifeldman@gmail.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 5041311C3 for ; Sun, 23 Aug 2015 00:28:01 +0000 (UTC) (envelope-from brianfundakowskifeldman@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 4CBCC9C0CB1; Sun, 23 Aug 2015 00:28:01 +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 4C3D89C0CB0 for ; Sun, 23 Aug 2015 00:28:01 +0000 (UTC) (envelope-from brianfundakowskifeldman@gmail.com) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (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 13BD811C2; Sun, 23 Aug 2015 00:28:01 +0000 (UTC) (envelope-from brianfundakowskifeldman@gmail.com) Received: by iodb91 with SMTP id b91so115562084iod.1; Sat, 22 Aug 2015 17:28:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=w014LNtlTdwBEUi2Mfmoj3HDnUYvzXZruNnhhzBX+3g=; b=iRdBM1XaXsMectaDhLHCNSAOMcIkb+zWa4k+y1nKhiqMu3Sz5nwwa8zizt4BtyXMJV 0oH+DZZCxpTrlsedrKo+VMZFkpbiYdnEdkBjr9LKcdZxKQE0W/84ZNyPrllh7Fb83v1b aOvBJs1hVlXRIvGTqUzYgyugbFgyObh6rOxV7LI94B0OkaJP6KRBmoXQOjFQNWimTXK8 2yctPuBEzm4MniLeRqcUws89NpmOHQdvFGBWwRb8RpMKWeRBgsj+SL7sIwBa9RDMvXnv pJcjq0CEeL704drBisjPFojWyNl9VKD5U/TJTAV6WBccVvalZ6zaF4t0eZYlu0pkLHN0 XT2w== X-Received: by 10.107.153.5 with SMTP id b5mr16814671ioe.143.1440289680225; Sat, 22 Aug 2015 17:28:00 -0700 (PDT) MIME-Version: 1.0 References: <20150817160423.GB3078@gmail.com> In-Reply-To: From: Brian Fundakowski Feldman Date: Sun, 23 Aug 2015 00:27:50 +0000 Message-ID: Subject: Re: spigen(4) SPI Generic IO interface -- need comments To: Warner Losh 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:28:01 -0000 You know, now you're making me wonder if the edge behavior shouldn't also be configurable per-spigen/per-transfer. Chip select polarity seems far too dangerous to expose that way. The only SPI device I have lying around so far is an MCP3008. On Sat, Aug 22, 2015, 8:17 PM Warner Losh wrote: > 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" >> > > From owner-freebsd-embedded@freebsd.org Sun Aug 23 00:28:27 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 638C89C0CD9 for ; Sun, 23 Aug 2015 00:28:27 +0000 (UTC) (envelope-from karl@denninger.net) Received: from fs.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "NewFS.denninger.net", Issuer "NewFS.denninger.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 313B811F9 for ; Sun, 23 Aug 2015 00:28:26 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (localhost [127.0.0.1]) by fs.denninger.net (8.15.2/8.14.8) with ESMTP id t7N0SJGv007057 for ; Sat, 22 Aug 2015 19:28:19 -0500 (CDT) (envelope-from karl@denninger.net) Received: from [192.168.1.40] [192.168.1.40] (Via SSLv3 AES128-SHA) ; by Spamblock-sys (LOCAL/AUTH) Sat Aug 22 19:28:19 2015 Message-ID: <55D9137A.4000403@denninger.net> Date: Sat, 22 Aug 2015 19:27:38 -0500 From: Karl Denninger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: freebsd-embedded@freebsd.org Subject: Re: spigen(4) SPI Generic IO interface -- need comments References: <20150817160423.GB3078@gmail.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060809040503060505040407" 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:28:27 -0000 This is a cryptographically signed message in MIME format. --------------ms060809040503060505040407 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable This is extremely cool stuff, and will make adding analog inputs to the Pi under FreeBSD easy..... which is exactly what I needed as a gating function for a project I wanted to undertake. On 8/22/2015 13: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 w= rote: >>>> I'm woefully out-of-practice with my kernel hackery (but still prett= y >>>> 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 tha= n >>> 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 anyon= e >>> wants >>>> but it's very trivial: I just align the start bit and the command da= ta >>> 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 t= wo >>>> 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]. Hav= e you >>> considered adding some of the ioctls[3] or the data structures to mak= e it >>> easier to port code? >>> >>> [1]: >>> https://lists.freebsd.org/pipermail/freebsd-embedded/2015-April/00246= 6.html >>> [2]: https://www.kernel.org/doc/Documentation/i2c/dev-interface >>> [3]: >>> https://www.freebsd.org/cgi/man.cgi?query=3Diic&apropos=3D0&sektion=3D= 0&manpath=3DFreeBSD+10.2-RELEASE&arch=3Ddefault&format=3Dhtml >>> [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 mo= de, >> as well. I don't like the Linux APIs one bit because it's just not sa= fe 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= =2Eorg" --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms060809040503060505040407 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGXzCC BlswggRDoAMCAQICASkwDQYJKoZIhvcNAQELBQAwgZAxCzAJBgNVBAYTAlVTMRAwDgYDVQQI EwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0BCQEWE0N1ZGEg U3lzdGVtcyBMTEMgQ0EwHhcNMTUwNDIxMDIyMTU5WhcNMjAwNDE5MDIyMTU5WjBaMQswCQYD VQQGEwJVUzEQMA4GA1UECBMHRmxvcmlkYTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExMQzEe MBwGA1UEAxMVS2FybCBEZW5uaW5nZXIgKE9DU1ApMIICIjANBgkqhkiG9w0BAQEFAAOCAg8A MIICCgKCAgEAuYRY+EB2mGtZ3grlVO8TmnEvduVFA/IYXcCmNSOC1q+pTVjylsjcHKBcOPb9 TP1KLxdWP+Q1soSORGHlKw2/HcVzShDW5WPIKrvML+Ry0XvIvNBu9adTiCsA9nci4Cnf98XE hVpenER0qbJkBUOGT1rP4iAcfjet0lEgzPEnm+pAxv6fYSNp1WqIY9u0b1pkQiaWrt8hgNOc rJOiLbc8CeQ/DBP6rUiQjYNO9/aPNauEtHkNNfR9RgLSfGUdZuOCmJqnIla1HsrZhA5p69Bv /e832BKiNPaH5wF6btAiPpTr2sRhwQO8/IIxcRX1Vxd1yZbjYtJGw+9lwEcWRYAmoxkzKLPi S6Zo/6z5wgNpeK1H+zOioMoZIczgI8BlX1iHxqy/FAvm4PHPnC8s+BLnJLwr+jvMNHm82QwL J9hC5Ho8AnFU6TkCuq+P2V8/clJVqnBuvTUKhYMGSm4mUp+lAgR4L+lwIEqSeWVsxirIcE7Z OKkvI7k5x3WeE3+c6w74L6PfWVAd84xFlo9DKRdU9YbkFuFZPu21fi/LmE5brImB5P+jdqnK eWnVwRq+RBFLy4kehCzMXooitAwgP8l/JJa9VDiSyd/PAHaVGiat2vCdDh4b8cFL7SV6jPA4 k0MgGUA/6Et7wDmhZmCigggr9K6VQCx8jpKB3x1NlNNiaWECAwEAAaOB9DCB8TA3BggrBgEF BQcBAQQrMCkwJwYIKwYBBQUHMAGGG2h0dHA6Ly9jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNV HRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCBeAwLAYJYIZIAYb4QgENBB8W HU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0GA1UdDgQWBBTFHJQt6cloXBdG1Pv1 o2YgH+7lWTAfBgNVHSMEGDAWgBQkcZudhX383d29sMqSlAOh+tNtNTAdBgNVHREEFjAUgRJr YXJsQGRlbm5pbmdlci5uZXQwDQYJKoZIhvcNAQELBQADggIBAE9/dxi2YqjCYYhiybp4GKcm 7tBVa/GLW+qcHPcoT4dqmqghlLz8+iUH+HCJjRQATVGyMEnvISOKFVHC6aZIG+Sg7J8bfS4+ fjKDi9smRH2VPPx3bV8+yFYRNroMGHaPHZB/Xctmmvc+PZ9O2W7rExgrODtxIOB3Zs6wkYf+ ty+9r1KmTHlV+rRHI6timH1uiyFE3cPi1taAEBxf0851cJV8k40PGF8G48ewnq8SY9sCf5cv liXbpdgU+I4ND5BuTjg63WS32zuhLd1VSuH3ZC/QbcncMX5W3oLXmcQP5/5uTiBJy74kdPtG MSZ9rXwZPwNxP/8PXMSR7ViaFvjUkf4bJlyENFa2PGxLk4EUzOuO7t3brjMlQW1fuInfG+ko 3tVxko20Hp0tKGPe/9cOxBVBZeZH/VgpZn3cLculGzZjmdh2fqAQ6kv9Z9AVOG1+dq0c1zt8 2zm+Oi1pikGXkfz5UJq60psY6zbX25BuEZkthO/qiS4pxjxb7gQkS0rTEHTy+qv0l3QVL0wa NAT74Zaj7l5DEW3qdQQ0dtVieyvptg9CxkfQJE3JyBMb0zBj9Qhc5/hbTfhSlHzZMEbUuIyx h9vxqFAmGzfB1/WfOKkiNHChkpPW8ZeH9yPeDBKvrgZ96dREHFoVkDk7Vpw5lSM+tFOfdyLg xxhb/RZVUDeUMYIE4zCCBN8CAQEwgZYwgZAxCzAJBgNVBAYTAlVTMRAwDgYDVQQIEwdGbG9y aWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBMTEMxHDAa BgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0BCQEWE0N1ZGEgU3lzdGVt cyBMTEMgQ0ECASkwCQYFKw4DAhoFAKCCAiEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTUwODIzMDAyNzM4WjAjBgkqhkiG9w0BCQQxFgQUlh+sWchUEFbp 6gO4+9EhOjRsvnYwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAEC MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzAN BggqhkiG9w0DAgIBKDCBpwYJKwYBBAGCNxAEMYGZMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBAgEpMIGpBgsqhkiG9w0BCRACCzGBmaCBljCBkDELMAkGA1UE BhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQ Q3VkYSBTeXN0ZW1zIExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqG SIb3DQEJARYTQ3VkYSBTeXN0ZW1zIExMQyBDQQIBKTANBgkqhkiG9w0BAQEFAASCAgB5vqQu sFCqGWwi+lCHmUtZyXLZusLqrUTVGT/pey3apv1Lr8ws4i7GqzZxMFNUWIZ3+Mx0va2YYhaV BmBOZZILTqpnBtcK/W4vJG4rq0nE3fY8JrzVLCwXJGaaQKVxkGMOj5dvLkFkVUB5hgTOfRjS HW7OiMEH+Ixpmua61SxOWGdyNLUI3SuTkzs7QpFa+RZi/RsNtGB3q5fI9e6AWTxX6bgYVLmk T3XlTxWtawyJF/UHTyi2wUaojYrJVa6QEi3Xr1oLUtmCOzrNQ/ddKR53JRpmW8/9SnkEwybl CmHY/Dp85vxZQlySPYQ4zk3r6o9/76Kxb9hFIUgPeO0D0lRn0v7eSKJCqJYYR3LVUlPbr+bn gGdtOsoXxpLwHbaAr2wIWVbIESxtGUbzFCu1rbFC1X91ttMzzchnI/1EuRUwGzf+prbMEYq+ iJGoaAlyRCqX3yzADEguJdn9UMI/KfF79WOWW60722NrXUgiV/XGHNq2PSVcmKc1swlO3M6T 7Go+a0FB34UV1VBmA2mlOejHoWxioMTbMx7HrF6RdABoXKFjtyHNlCZ4KKiTLQdk2Y68O8Kx umQCNlk3I7STntDAkQ1J0VuNJG7JUyMcTUIQsySn3617XM5oRFztAvVExZTByVZNJ3p1PqIp K19HGKRq3dD/TfFyBYPf0+afhbQqOgAAAAAAAA== --------------ms060809040503060505040407--