Rpi 4.4.y spi aux

[frasersdev]

Hi,
As per this post https://www.raspberrypi.org/forums/viewtopic.php?p=909123#p909123 I am submitting a pull request to enable the SPI1 & 2 'Auxiliaries' in kernel 4.4 for the purpose of establishing it if could be applied. Note that it requires back porting of the auxiliary clock. This pull request also resolves this issue #1034

The first two commits are the back porting of the auxiliary clock from 4.5 along with associated documentation and bindings. The third commit is the changes needed to build the code for rPI hardware and make these SPI auxiliaries available to end users via device tree configuration. To enable add 'dtparam=spi1_aux=on' or 'dtparam=spi2_aux=on' (compute module) into the /boot/config.txt

Apart from the obvious there are some items that might be worth discussing:

1. Naming convention - even broadcom is inconsistent with the naming of these two SPI devices. I have elected for spi1_aux and spi2_aux.

2. uart1 clock - this probably needs to be looked at as it can probably be reconfigured to use the aux clock.

Configuration is based on header availability:

• PI A/B - neither
• PI A+/B+/Zero & PI2 B - spi1
• PI compute module - sp1,spi2

I do not have a PI A+/B+/Zero/compete module so this hardware is untested
I have however tested the SPI1 driver on a rPI2 B.

$ uname -a
Linux raspberrypi 4.4.2-v7 #1 SMP Sat Feb 20 09:23:06 UTC 2016 armv7l GNU/Linux

Loopback test on spi1.1

$ ./spidev_test -D /dev/spidev1.1 -v
spi mode: 0x0
bits per word: 8
max speed: 500000 Hz (500 KHz)
TX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D  | ......@....?..................?.
RX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D  | ......@....?..................?.

Reading a MCP3202 via spi1.0

$ ./spi-mcp3202 
sample 2131, volts 1.717v
sample 2132, volts 1.718v
sample 2131, volts 1.717v
sample 2131, volts 1.717v
sample 2132, volts 1.718v

[popcornmix]

@msperl @notro @vlad-zakharov @pelwell comments welcome.

[notro]

Can this be dropped, it just confuses by indicating that 3 chip selects are mandatory:

+           cs-gpios = <0>, <0>, <0>;

I suggest putting the spi1/2 setup into overlays instead of the board files: spi1-spidev-overlay.dts

Not everyone wants 3 chip selects. Maybe we can have 3 chip select nodes in the overlay which enables 1, 2 or 3 chip selects:
dtoverlay=spi1-spidev,cs1
dtoverlay=spi1-spidev,cs2
dtoverlay=spi1-spidev,cs3

@pelwell Is there a way to to use an overlay parameter to tell which spi bus to use (ie. which spi bus node to attach a device to)?
If so we could have one overlay to enable a spi bus with a certain number of chip selects, and one generic overlay to add a configurable number of spidev nodes on any spi bus.
This would be handy for spi overlays so they can be used with all spi busses.
Maybe like this: 3 chip selects on spi1 and add a spidev node on 2 and 3:
dtoverlay=spi1,cs3
dtoverlay=spidev,bus=1,cs2,cs3

Even better if we could set the gpio for a variable number of cs-gpios (including pinmux):
dtoverlay=spi1,cs0=18
dtoverlay=spi1,cs0=18,cs1=17
dtoverlay=spi1,cs0=18,cs1=17,cs2=16

[msperl]

@notro: this goes back to the discussion about indexes and the fact that one overlay can only get loaded once - not different times with different parameters.

Otherwise you could run this:

dtoverlay=spi1
dtoverlay=spi1-cs,cs=0,gpio=20
dtoverlay=spi1-cs,cs=1,gpio=21
dtoverlay=spi2
dtoverlay=spi2-cs,cs=0,gpio=22
dtoverlay=spi2-cs,cs=1,gpio=23

if you could also parametric the name it could even become:

dtoverlay=spiX-cs,dev=spi1,cs=0,gpio=20
dtoverlay=spiX-cs,dev=spi1,cs=1,gpio=21
dtoverlay=spiX-cs,dev=spi2,cs=0,gpio=22
dtoverlay=spiX-cs,dev=spi2,cs=1,gpio=23
dtoverlay=spiX-cs,dev=spi2,cs=1,gpio=24
dtoverlay=spidev,dev=spi1_1
dtoverlay=spidev,dev=spi2_3

[frasersdev]

FWIW I agree with @notro about making the SPI configuration configurable with overlays & dtparams.

I have a working example: frasersdev@5d4a4a1
(incomplete, for a rpi2 & spi1 only)

So three overlays, one each for 1,2,3 CS lines. Each CS line can be mapped to a gpio by a user and also the spi device node can be disabled.

Its not the neatest solution having a few overlays per spi device but if I understand @msperl properly then that compromise may not be avoidable.

Example usage: spin up spi1 with 2 cs lines. use pin 30 for cs0 and & 31 for cs1. only create a /dev/spidev1.0 node
dtoverlay=spi1-2cs,cs0_pin=30,cs1_pin=31,cs1_spidev=disabled

this sets up spi1 like so:

pi@raspberrypi:~ $ ls -l /dev/spi*
crw-rw---- 1 root spi 153, 0 Feb 21 06:33 /dev/spidev0.0
crw-rw---- 1 root spi 153, 1 Feb 21 06:33 /dev/spidev0.1
crw-rw---- 1 root spi 153, 2 Feb 21 06:33 /dev/spidev1.0
pi@raspberrypi:~ $ hexdump /sys/firmware/devicetree/base/soc/spi@7e215080/cs-gpios
0000000 0000 0a00 0000 1f00 0000 0100 0000 0a00
0000010 0000 1e00 0000 0100                    
0000018
pi@raspberrypi:~ $ hexdump /sys/firmware/devicetree/base/soc/gpio@7e200000/spi1_cs_pins/brcm,pins
0000000 0000 1f00 0000 1e00                    
0000008

So is that heading in the right direction?

[pelwell]

@msperl is quite right about the limitations of the overlay mechanism. I've had a back-burner project since last year to extend the syntax to allow names to be parameterised along with some more radical changes, but the challenges are:

1. to make the new syntax logical, readable, flexible and not too cumbersome,
2. to maintain support for the existing syntax, ideally in a way that makes the new version a natural extension of its predecessor, and
3. to find the time.

There is also a tension between wanting to get something out soon that at least manages renaming nodes, and wanting to minimise the number of iterations, or at least not to miss out on future opportunities by insufficient planning.

@notro was kind enough to give me some feedback on a early draft which led to several improvements, but then my ideas grew along with my other challenges. The implementations so far have all been fairly straightforward - the what is much harder than the how - so if there's an appetite for progress in this area then I may create an issue here and invite comments from those interested and knowledgeable in the field.

Until then, @frasersdev I think your approach is the best you can do under the circumstances. If you add descriptions into the README and create a pull-request I'll happily merge it.

[msperl]

@pelwell: maybe it would be better if we started using the device-tree overlays in kernles and find some way to feed the experience we see/have into that - worsted case by having a DTS-overlay translator or similar that runs only in user-space (also for backwards compatiblity support)

I guess this would make all our lives easier in the long run - especially for yours, as the support for DT-overlays in the firmware goes away...

[frasersdev]

@pelwell sure will do.

A question while everyone is here - the spi-max-frequency for spi0 is 500khz which is a bit on the low side (i.e. for driving lcd screens or SD cards). I've see the hardware successfully used up to 10Mz and beyond. I'm unaware of the history behind the speed limit for spi0 and so cannot determine if it also applies spi1/2 or not.

Is there any harm is bumping that up a bit for spi1/2 in the dtoverlays I'm going to submit? say 10Mhz?

[notro]

I don' think this matters much when using spidev since there's an ioctl to set the speed (SPI_IOC_WR_MAX_SPEED_HZ) but I could be wrong, haven't seen many spidev-using programs.
500k is a good default I think, should "just work" with most devices.
When it comes to kernel drivers/users the speed is usually configurable using an overlay parameter.

[frasersdev]

@notro
Ok had a chance to go into this. You are correct, I was being led astray by the use of 'max'.
Its just the initial value for the spi clock and can be overridden with a SPI_IOC_RD_MAX_SPEED_HZ ioctl. I can run mine up to 32mhz before devices start misbehaving.

I guess this pull request can be closed now then?