Can you post the snippet of the change to board-omap3logic.c? If you'd prefer, we can send you a file transfer request if you don't want to publish it publicly.

adam

Thanks Adam,
The snippet is below. I'm calling it right after the omap3torpedo_fix_pbias_voltage() function in omap3logic_init().

static void omap3_init_dutSpi(void)
{
    static struct spi_board_info omap3logic_spi1_to_dut[] __initdata = {
    {
        .modalias                = "spidev",
        .bus_num               = 1,
        .chip_select           = 0,                         /*dut #1*/
        .max_speed_hz   = 1000000,           /*1MHz*/
        .irq                           = 0,
        .platform_data      = NULL,
        .bits_per_word     = 8,
        .mode                     = SPI_MODE_3,
    },
    {
        .modalias            = "spidev",
        .bus_num            = 1,
        .chip_select        = 1,                           /*dut #2*/
        .max_speed_hz = 10000000,          /*10MHz*/
        .irq                        = 0,
        .platform_data    = NULL,
        .bits_per_word   = 32,
        .mode                   = SPI_MODE_3,
    }
    };

    spi_register_board_info(omap3logic_spi1_to_dut,
                            ARRAY_SIZE(omap3logic_spi1_to_dut));
}

I also have some mux initialization code that is called before the SPI is registered:

#define SPI1_CLK_MUX   "mcspi1_clk"
#define SPI1_SIMO_MUX "mcspi1_simo"
#define SPI1_SOMI_MUX "mcspi1_somi"
#define SPI1_CS0_MUX  "mcspi1_cs0"
#define SPI1_CS1_MUX  "mcspi1_cs1"

err |= omap_mux_init_signal(SPI1_SOMI_MUX, OMAP_PIN_INPUT);
err |= omap_mux_init_signal(SPI1_SIMO_MUX, OMAP_PIN_INPUT);
err |= omap_mux_init_signal(SPI1_CLK_MUX, OMAP_PIN_INPUT);
err |= omap_mux_init_signal(SPI1_CS0_MUX, OMAP_PIN_INPUT);
err |= omap_mux_init_signal(SPI1_CS1_MUX, OMAP_PIN_INPUT);

-Derek

I don't see anything out of the ordinary. I don't have a board in front me to test, but I would suggest muxing the pins with OMAP_PIN_INPUT_PULLUP instead of OMAP_PIN_INPUT

You may also want to consider doing the pin muxing in the bootloader. An external pull-up might help too.

I'll talk with a colleague too and see if he has suggestions.

adam

I had the same thought about the pull-up, but unfortunately in OMAP_MUX_MODE0, the signal is just driven low any ways. If I use OMAP_MUX_MODE4, the pull-up actually sets the pin high, but it is no longer controlled through the SPI hardware.

Derek,

You mention that you have multiple SPI slave devices on the bus. Can you explain how the chip select signals are connected to your slave devices?

Thanks,
Brad

Hi,
Sure, I have mcspi1_cs0 going to the CS input on one SPI peripheral. I have mcspi1_cs1 going to the CS input on the other SPI peripheral.

-Derek

 

Derek,

Assuming both devices require active high chip select signals, can you explain why you need the chip select signal to go high before accessing the SPI device in user space? What error is occurring due to the fact that the SPI chip signal signal is remaining low?

Thanks,
Brad

Hi Brad,
Both devices are active-low chip-selects. I need the CS outputs to idle high immediately so that the two peripherals aren't activated at the same time.

I think there may be some confusion with the title of my question. By "Activate SPI Signals", I intended to say that I want the SPI signals to go to their idle states immediately in the BSP. The SPI signals don't seem to go to their idle state until the spi device is opened in user space.

 -Derek

Derek,

I believe I found another person who ran into a similar problem. They ended up using single channel mode to get the chip select to the correct state before changing the pin's alternate function. Here is the link to the information I found.

http://e2e.ti.com/support...a_arm/f/791/t/262817

I also sent this out to our engineering team to see if they have any experience with this same issues. If I learn any additional information on this topic I will be sure to add it here.

Thanks,
Brad

Hi Brad,
Thanks, that does look like the exact same thing I'm running into. It's good to know others came across this too. It wouldn't surprise me if there is a more elegant solution. I'm also unsure if I can use the single channel mode during initialization since I have multiple slaves. Please keep me updated if you hear anything from the team.

-Derek

Derek,

After reviewing the posting it seems the main objective is get the SPI signals out of their reset state. In the datasheet it shows the nCS signals reset state as low. Therefore once the SPI controller starts to drive the signals, they should behave correctly.

Whatever method you decide to use you might consider delaying changing the SPI signals mux configuration until after the SPI controller has them in their deactive state.

Thanks,
Brad