spi speed on up squared 6000 does not go over 1MHz

fvllml

I want to communicate through spi from an up2 6000 and a microcontroller. On the up2 I am using ubuntu 20.04 with kernel 5.13 and the PREEMT_RT patch

Linux up 5.13.0-rt1 #1 SMP PREEMPT_RT Thu Oct 13 12:09:18 CEST 2022 x86_64 x86_64 x86_64 GNU/Linux

my program to communicate through spi sets the speed like this:

    int file_desctiptor = open("/dev/spidev1.0", O_RDWR);
    if (file_desctiptor < 0) {
        return -2;
    }

    // Set the spi mode
    if (ioctl(file_desctiptor, SPI_IOC_WR_MODE, (SPI_MODE_1 | SPI_CS_HIGH)) < 0) {
        close(file_desctiptor);
        return -3;
    }

    // Set the spi speed
    uint32_t speed{8000000};
    if (ioctl(file_desctiptor, SPI_IOC_WR_MAX_SPEED_HZ, &speed) < 0) {
        close(file_desctiptor);
        return -4;
    }

But on the logic analyzer the spi clock frequency never goes over 1MHz. However, when I change the speed value for less than 1MHz it actually works, so it must be a maximum set somewhere.

I also tried to read back the speed after setting it up like this:

    // Read the spi speed
    uint32_t actual_speed;
    if (ioctl(file_desctiptor, SPI_IOC_RD_MAX_SPEED_HZ, &actual_speed) < 0) {
        close(file_desctiptor);
        return -5;

And I was getting 8MHz but the clock on the logic analyzer was still 1MHz. I also got some logs of the linux kernel

The spidev driver is telling me the speed has been set correctly but the intel driver says the actual speed is 1MHz.

To enable spidev on the up2 6000 I use ACPI overloads. I also modified the max speed here:

/*
 * This ASL can be used to declare a spidev device on SPI1 CS0
 */
DefinitionBlock ("", "SSDT", 5, "INTEL", "SPIDEV0", 0x00000001)
{
    External (_SB.PC00.SPI1, DeviceObj)

    Scope (\_SB.PC00.SPI1)
    {
        Device (TP0)
        {
            Name (_HID, "SPT0001")  // _HID: Hardware ID
            Name (_DDN, "SPI test device connected to CS0")  // _DDN: DOS Device Name
            Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
            {
                SpiSerialBusV2 (0x0000, PolarityLow, FourWireMode, 0x08,
                    ControllerInitiated, 8000000, ClockPolarityLow,
                    ClockPhaseFirst, "\\_SB.PC00.SPI1",
                    0x00, ResourceConsumer, , Exclusive,
                    )
            })
        }
    }
}

Any idea of what I am missing?

fvllml

I have read back the speed using SPI_IOC_RD_MAX_SPEED_HZ and it is 8MHz but still on my logic analyzer I can see 1MHz.

I compiled my kernel with some logs to see what was happening in the drivers and I got this:

Apparently there are two instances of pxa2xx-spi driver, I suppose one is internal and we don't have much access (the first one with frequency 100MHz) and the other one is the one connected to the GPIO (so with frequency max limit of 990099 Hz).

Then, the SPT0001 acpi module tries to modify this frequency to be 8MHz but as it is bigger than the one of the controller the driver does not set it. Finally, I try to open a file descriptor for spi exchanges at 10MHz and again the driver refuses to open it because the controller has a smaller frequency.

Where is this frequency limit set? I tried compiling the kernel with different configurations but it didn't change. Is it something related to the hardware itself? or perhaps another acpi that I am missing?

Wilbert

Hi Sir,

Your question has been received, and the relevant personnel are confirming it.
If there are any updates, we will reply here.

Wilbert

Hi Sir,

Currently confirming with the software team.
I have seen this problem, it seems that there is a problem at linux driver or something else, and the software engineer are dealing with it.
I have tried to change to Windows test to confirm that the hardware is no problem, SPI can up to 8MHz at Windows.

mafish

@Wilbert are there any news on the fix to the issue? I am expiriencing the same problem.

bot

I encountered the same issue on UP-Squared-V2 where the SPI frequency is locked at 990099 Hz.

My kernel version is Linux debian 6.1.0-0.deb11.5-amd64.

there any news on the fix to the issue?

mafish

@bot @Wilbert has answered my PM, and said it's related to Intel CPU implementation in linux kernel - there are no plans to focus on it any time soon. It seems we are left to fix it ourselves or try to interest some Intel kernel engineer
In my case, switching a platform to a different board will be much easier solution.