Re: SPI driver

[mlelstv%serpens.de@localhost (Michael van Elst)]

swiftgriggs%gmail.com@localhost (Swift Griggs) writes:

>On Thu, 7 Feb 2019, Michael van Elst wrote:
>> I've written a userland interface to our spi(4) driver.

>Neat. I'm interested in SPI, but pardon me if I am a bit ignorant. If you 
>don't have time to answer it's no problem.

>> crw-------  1 root  wheel  346, 0 Jan  5 16:02 /dev/spi0

>I assume there is no concept of a block-mode for SPI, directly. It's only 
>a transport like I2C or JTAG right? Don't SD cards use it for IO or 
>something related ?

SPI is a transport like I2C.

SD cards used an SPI interface but usually switch to a faster protocol.
If you want to connect a SD card, you would need to attach an sdmmc
driver on top spi (and first program an attachment for it).

But this here is about userland access to the SPI controller. You could
write userland code that talks to an SD card connected to it. Nothing
really useful or efficient, but maybe good enough for testing.


>> SPI_IOCTL_CONFIGURE calls spi_configure() to chose operational mode and 
>> clock.

>I see the struct sets a clock in Hz. Is SPI always synchronous ?

SPI is a very dumb interface. You select a slave (with a dedicated enable
signal), then start the clock that synchronously shifts out and in bits at
the same time.


>Can one 
>vary the clock frequency ?

SPI doesn't define the clock frequency, depending on the specific hardware
capabilities, you could have arbitrary frequencies, also different frequencies
per connected slave. A common parameter is phase and polarity of the clock,
that's the "mode" passed to spi_configure().

Saying that, our spi driver doesn't handle per-slave frequencies.
It assumes that all use the same frequency and the configuration is
always done for the minimum.


>Is there a way to sense what the other side 
>will max out at ?

No, SPI is dumb. You need to know what to talk to.


>How can one know the width of data-bits in a cycle or 
>does it not matter and you just set sendlen & recvlen and not worry about 
>it ?

SPI itself doesn't know about width of data-bits. It transmits a serial
bit stream. Our driver is limited to transmit a byte-length buffer, so
it's always a multiple of 8 bits.

There are supposed to be controllers that assemble/disassemble
bit streams into various word-lengths, but we don't support that.


>> The interface is different from spigen(4) used by FreeBSD and also 
>> different from an early example of an SPI driver by Jonathan Kollasch.

>Why didn't you just steal it? I'm kidding, but still a bit curious.

spigen does the same as my driver, but the model is a bit different
as is the lower-level spi interface used by FreeBSD. We aren't
compatible to FreeBSD in other such areas, so sharing the interface
for SPI but not e.g. for I2C seemed to have little value.

Jonathan's example was just an example. It tries to model each slave
as a unit, similar to the spidev driver of Linux. Unfortunately
that's not supported by the current kernel interface.



>> As there is no kind of session handling,

>Is SPI meant to be stateful but the driver can't do it yet or is that just 
>how SPI works intrinsically ?

SPI is just about sending and receiving bits. It's about the driver that
has no idea about when a specific configuration should be used and
when it can be changed. For userland you could use the open/close
calls, but the kernel interface doesn't have that.

One possibility is to have a configuration per-transaction, i.e. switch
frequency and mode for each transfer. Depending on the hardware this
may introduce some unpleasant overhead. Linux drivers or a driver
following Jonathan's example have this problem. I know that some
Linux drivers try to optimize this by deferring the configuration
until there is a real change.


>Isn't it kinda low level bit-banging stuff 
>where you control which wire is doing what and who's on edge vs level 
>etc... ? So, you're saying "sessions" are just the responsibility of the 
>user/implementer, right ?

It's a bit higher level than bit-banging and SPI defines what wire is
doing what. In particular you have one or more enable signals (CE0, CE1,...)
a clock driven by the master, an output line (MOSI = master out slave in)
and an input line (MISO = master in slave out).


N.B. X-posting to tech.kern.

Greetings,
-- 
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."