BCM2835 LoSSI Clock Output

[mmader87]

Describe the bug
I know the Linux Kernel does not natively support LoSSI (this is something I am working on).
However the BCM2835 SPI Driver in LoSSI Mode outputs 10 clock cycles instead of 9 clock cycles as indicated by the BCM2835 ARM Peripherals spec.

To reproduce
Add code to enable LoSSI in function bcm2835_spi_transfer_one() and send one byte of data.
cs |= BCM2835_SPI_CS_LEN;

Note: SPI Mode is set to SPI_MODE_3 and SPI_3WIRE

Expected behaviour
Expect 9 clock cycles

Actual behaviour
Measured 10 clock cycles

System
Raspberry Pi CM3+ w/ IO Board
Kernel Version: v5.3.7-yocto-standard
Firmware Date: Aug 22 2019 14:00:42
Firmware Version: 0e6daa5106dd4164474616408e0dc24f997ffcf3 (clean) (release) (start_x)

[pelwell]

A bit of background on what LoSSI is and how to configure the SoC to enable that mode would help, but if Linux doesn't officially support LoSSI and after modifications by you it isn't working as expected, then either you've got something wrong in your changes or the hardware can't do it.

[mmader87]

@pelwell, Thank you for your response. I recommend reading the Broadcom ARM peripherals guide for the background you requested.
(https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2835/BCM2835-ARM-Peripherals.pdf)

LoSSI is a SPI mode that is supposedly supported by the RPI and is enabled by writing to the CS register in the SPI Address Map.

[mmader87]

Please also note, just by setting bit 13 of the aforementioned CS register in the SPI Address Map pushes out 10 clock cycles instead of 8 clock cycles. So yes, the hardware supports it and no this is not something I can control via the linux kernel.

I have a suspicion this is something controlled in the RPI Firmware mentioned above.

[mmader87]

Transmitting one byte or multiple bytes will show this error. In the below example, the first 5 bytes are transmitted correctly with 9-bits each. The last byte is transmitted with an extra clock cycle, making it 10-bits:

[pelwell]

The firmware does not access the SPI peripheral at all, so if the hardware isn't behaving as expected then either the expectation is wrong or there's a bug in the hardware.

[pelwell]

I'd say it's a hardware glitch that you see before the CE is released, rather than within a transfer. Since the hardware shouldn't do anything before the end of the command/data word is received, and all state should be lost when CE is released, then it's hard to see how it can do any harm.