Date: Mon, 17 Aug 2015 17:13:51 +0000 From: Brian Fundakowski Feldman <brianfundakowskifeldman@gmail.com> To: Tom Jones <jones@sdf.org> Cc: hackers@freebsd.org Subject: Re: spigen(4) SPI Generic IO interface -- need comments Message-ID: <CAEv1%2BOUdWMngTaqf004Rjmt%2BLkEaZeR_H%2B%2B1RMQAGzBZFbYYHw@mail.gmail.com> In-Reply-To: <20150817160423.GB3078@gmail.com> References: <CAEv1%2BOU4cFpMpeQGfnCP7L4Q_k18rOSOA9JBnKUa99DS5dFnWA@mail.gmail.com> <20150817160423.GB3078@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Oh, no, I couldn't find that in the search but maybe I need to subscribe to -embedded now that I'm interested in circuit hacking with my Pi. I am interested in also doing an i2c interface so I can use an I/O multiplexer as well. I'll have to take a look at your code, maybe try and shape them up into something good enough to commit -- I think I want to have a root-owned sysctl dictating the maximum transfer lengths (and hence pinned memory). On Mon, Aug 17, 2015, 12:04 PM Tom Jones <jones@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 > > - tj >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAEv1%2BOUdWMngTaqf004Rjmt%2BLkEaZeR_H%2B%2B1RMQAGzBZFbYYHw>