This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

L137 SPI drivers

Other Parts Discussed in Thread: DA8XX

Following up on this thread:

http://e2e.ti.com/support/embedded/f/354/p/145232/527422.aspx

I was able to test the /dev/spidev0.1 driver with the spidev_test test program and all seems to work well on the L137 EVM using pins on the expansion header. 

Now I have a new problem. I need to setup a spidev driver on the SPI1 bus.  I added the [2] entry to the spi_board_info structure as follows:

static struct spi_board_info da830evm_spi_info[] = {
    [0] = {
        .modalias        = "m25p80",
        .platform_data        = &da830evm_spiflash_data,
        .controller_data    = &da830evm_spiflash_cfg,
        .mode            = SPI_MODE_0,
        .max_speed_hz        = 30000000,    /* max sample rate at 3V */
        .bus_num        = 0,
        .chip_select        = 0,
    },
    [1] = {
        .modalias         = "spidev",
        .mode            = SPI_MODE_0,
        .max_speed_hz        = 30000000,    /* max sample rate at 3V */
        .bus_num        = 0,
        .chip_select        = 1,
    },
     [2] = {
        .modalias         = "spidev",
        .mode            = SPI_MODE_0,
        .max_speed_hz        = 30000000,    /* max sample rate at 3V */
        .bus_num        = 1,
        .chip_select        = 0,
    },
};

Also added this definition

static struct davinci_spi_platform_data da830evm_spi1_pdata = {
    .version    = SPI_VERSION_2,
    .num_chipselect    = 1,
    .intr_line    = 1,
};

and this call:

ret = da8xx_register_spi(1, &da830evm_spi1_pdata);
    if (ret)
        pr_warning("failed to register spi 1 device : %d\n", ret);

---------------------------------------------------

This did successfully create the /dev/spidev1.0 file.   But the using it with the spidev_test program hangs the EVM. 

# cat /dev/spidev1.0

also hangs the machine.  Below is the spi-related info from boot up .

spi_davinci spi_davinci.0: DMA: supported
spi_davinci spi_davinci.0: DMA: RX channel: 14, TX channel: 15, event queue: 0
m25p80 spi0.0: w25x32 (4096 Kbytes)
Creating 3 MTD partitions on "m25p80":
0x000000000000-0x000000040000 : "U-Boot"
0x000000040000-0x000000044000 : "U-Boot-Env"
0x000000044000-0x000000400000 : "Kernel"
spi_davinci spi_davinci.0: Controller at 0xfec41000
spi_davinci spi_davinci.1: DMA: supported
spi_davinci spi_davinci.1: DMA: RX channel: 18, TX channel: 19, event queue: 0
spi_davinci spi_davinci.1: Controller at 0xfef0e000

 

Any ideas on why this isn't working?  I haven't seen any examples of people using both spi busses with linux.

 

Thanks,

Keith

  • Not sure if this is the problem. See linux-03.21.00.0, arch/arm/mach-davinci/devices-da8xx.c, struct resource da8xx_spi1_resources. The base address of the SPI1 controller is specified as 0x01f0e000. The datasheet says 0x01e12000. The base address for SPI0 matches the datasheet. Your version of kernel may have been fixed already.

  • Norman, thanks for taking the time to answer.  Who knows how long it would have taken me to figure that out.  Yes, the address was wrong in the code I was using.  Here's the change I mage to the arch/arm/mach-davinci/devices-da8xx.c file

    static struct resource da8xx_spi1_resources[] = {
        [0] = {
    //        .start = 0x01f0e000,
    //        .end   = 0x01f0efff,

             .start = 0x01e12000,
             .end   = 0x01e12fff,
            .flags = IORESOURCE_MEM,
        },
      

    Now, using the file no longer hangs the EVM, but does produce a cleaner error

    # cat /dev/spidev1.0
    spi_davinci spi_davinci.1: SPI data transfer error
    cat: read error: Input/output error

    And, running spidev_test gives...

    # ./spidev_test -D /dev/spidev1.0
    spi mode: 0spi_davinci spi_davinci.1: SPI data transfer error

    bits per word: 8
    max speed: 3000000 Hz (3000 KHz)
    can't send spi message: Input/output error
    Aborted

    Any ideas?

  • Not sure. I've never used the ARM side Linux SPI driver. In theory, a SPI master should not care if a transfer succeeded or not. No idea why the driver would complain. However, the L137 SPI controller has that 5 pin mode where it might be able to tell if a transfer fails. Are getting stuff out the pins?

  • Pins appear dead for SPI1 test.

  • You might need to pinmux in the SPI1 lines. Try adding this to your board.c file at some point in the init.

    ret = davinci_cfg_reg_list(da830_spi1_pins);

    SPI0 is probably muxed in U-Boot.. Note that you will lose whatever was muxed into those pins.

     

  • Checking the muxing was going to be my next step.  But that did it!   But your post certainly simplified things.  I didn't know that function call.  SPI1 does share pins with UART2 which is the serial port I had my terminal on.   Had to use telnet to get in and see it working   Thank you so much for taking the time to help out.   I think you saved me a whole lot of time.