spigen(4) SPI Generic IO interface -- need comments

[Karl Denninger]

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 at gmail.com> wrote:
>
>> On Mon, Aug 17, 2015 at 12:04 PM Tom Jones <jones at sdf.org> 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 at freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-embedded
>> To unsubscribe, send any mail to "freebsd-embedded-unsubscribe at freebsd.org"

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2944 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-embedded/attachments/20150822/62031506/attachment.bin>