Date: Sat, 22 Aug 2015 18:17:20 -0600 From: Warner Losh <imp@bsdimp.com> To: Brian Fundakowski Feldman <brianfundakowskifeldman@gmail.com> Cc: Adrian Chadd <adrian.chadd@gmail.com>, Luiz Otavio O Souza <loos@freebsd.org>, "freebsd-embedded@freebsd.org" <embedded@freebsd.org> Subject: Re: spigen(4) SPI Generic IO interface -- need comments Message-ID: <CANCZdfo%2Bd2oA86iw_OXLros%2BBnVQZZqt2D_rWQMp-R6FNH5ueQ@mail.gmail.com> In-Reply-To: <CAEv1%2BOUycUtCiQ9ZVxZjwAkvW0JiGi26tDKpvzD12P1wyEkeQw@mail.gmail.com> References: <CAEv1%2BOU4cFpMpeQGfnCP7L4Q_k18rOSOA9JBnKUa99DS5dFnWA@mail.gmail.com> <20150817160423.GB3078@gmail.com> <CAEv1%2BOUhSAJxxWAfW2GUFVw=H-_KOs2dGg2d7uhZnFbqsHE5Qw@mail.gmail.com> <CAEv1%2BOXe4w8hJXQu2MsoMLz6ixeG3hU3BmLZpssG15SaPd9JGw@mail.gmail.com> <CAJ-Vmom4qgXYL5eMPsnprvO4X7CES5ipAc0Z%2BsZtmMmF9K4Fqg@mail.gmail.com> <CAEv1%2BOUycUtCiQ9ZVxZjwAkvW0JiGi26tDKpvzD12P1wyEkeQw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <adrian.chadd@gmail.com> 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 > > <brianfundakowskifeldman@gmail.com> 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 <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 > > >> > > >> > > >> 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 > " >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfo%2Bd2oA86iw_OXLros%2BBnVQZZqt2D_rWQMp-R6FNH5ueQ>