• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 100 subscribers
  • Views 1072 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Changing DM8148 SPI1 MOSI/MISO assignments

Jon S.
Expert 1240 points

Hi all,

Via the attached patch and the CONFIG_SPI_SPIDEV Linux kernel configuration item, I've enabled SPI1 (CS 0) for use by spidev (/dev/spidev2.0). After looking at the signals on a scope, everything seems to be working, except for the fact that my MOSI and MISO pins seemed to be swapped. (Perhaps someone could use my patch and spidev to double check this assertion?) With this setup, it appears that I'm seeing my output data on AA3.

In the DM8148 TRM I see that this is actually software-configurable via the DPE0, DPE1 bits of the MCSPI_CH<n>CONF register. However, at this point I'm still prototyping using spidev rather than modifying/extending the mcspi driver directly.

(1) Are there are any quick sysfs or kernel cmdline parameters I could use to specify the MOSI/MISO assignments of these pins, or perhaps a quick change to board_ti814xevm.c that I'm missing?

(2) I've been looking at the TRM and the PSP's McSPI Driver Guide, but didn't see anything about the default MISO/MOSI assignment of these pins (and/or what the McSPI driver sets them to initially). Would anyone happen to know what document/source file I should be looking at? I expect that I'm overlooking this...

(3) If the answer to (1) is "no," could anyone provide a bit of insight in where I should be looking to make changes? In the future I may be using devices on SPI0 which may not have the same SPIX_D[0/1] assignments, so I just want to keep that in mind.

Basically, I would like the SPI1_D[0/1] assignments to match what I see in the Mistral DM8148EVM schematic for the EVM base board (see pg 24 of MS_TI_CEN_BB_REVC_DDR3_PG2_SCH.pdf, rev C): AA6=SPI1_MOSI, AA3=SPI1_MISO. 

(4) [CORRECTION] I see that on the Mistral EVM Expansion board (see MS_TI_CEN_CAT_APP_BETA_SCH.pdf, rev B, page 5, connector J2) seems to have connected AA6 (Labeled SPI1_MOSI) to the SDO (ACC_SPI_DO) of the accelerometer on the board, and AA3 (Labeled SPI1_MISO) is attached to the SDI on the accelerometer (ACC_SPI1_DI).  The input/output arrow directions also seem to indicated that MISO and MOSI  have been mislabeled here.  Am I correct on this being a typo on the schematic?


Thank you,
Jon

Fullscreen 4885.spidev.patch.txt Download 
--- ../../../../linux-2.6.37-psp04.01.00.06.patch2.bak/arch/arm/mach-omap2/board-ti8148evm.c	2011-11-21 12:58:36.000000000 -0500
+++ ./board-ti8148evm.c	2012-02-28 15:29:03.018814557 -0500
@@ -480,6 +480,13 @@
 		.bus_num	= 1,
 		.chip_select	= 0,
 	},
+    {
+        .modalias = "spidev",
+        .mode   = SPI_MODE_0,
+        .max_speed_hz = 48000000,
+        .bus_num = 2,
+        .chip_select = 0,
+    },
 };
 
 void __init ti8148_spi_init(void)

  • 0
    Expert 1240 points

    It looks like my answer to (1) is "no" -- I see that omap2_mcspi_setup_transer() in omap2_mcspi.c assigns D1 to MOSI and D0 to MISO:

        l = mcspi_cached_chconf0(spi);

        /* standard 4-wire master mode:  SCK, MOSI/out, MISO/in, nCS
         * REVISIT: this controller could support SPI_3WIRE mode.
         */
        l &= ~(OMAP2_MCSPI_CHCONF_IS|OMAP2_MCSPI_CHCONF_DPE1);
        l |= OMAP2_MCSPI_CHCONF_DPE0;

    ...


        mcspi_write_chconf0(spi, l);

  • 0 in reply to Jon S.
    Intellectual 420 points

    Jon,

    Did you ever come up with a way to configure the pin assignments? For now, we are just modifying the driver code, as follows. But have you found a more flexible way to do this?

        /* standard 4-wire master mode:  SCK, MOSI/out, MISO/in, nCS
         * REVISIT: this controller could support SPI_3WIRE mode.
         */
    //    l &= ~(OMAP2_MCSPI_CHCONF_IS|OMAP2_MCSPI_CHCONF_DPE1);
    //    l |= OMAP2_MCSPI_CHCONF_DPE0;


    l &= ~(OMAP2_MCSPI_CHCONF_IS|OMAP2_MCSPI_CHCONF_DPE0);
    l |= OMAP2_MCSPI_CHCONF_DPE1;

  • 0 in reply to Joseph Waclawski
    Expert 1240 points

    Hi there Joseph,

    Fortunately (just for me, I suppose) we ended up just swapping some pins in hardware, so I never found the "clean" software solution I was looking for.

    One idea I had was to bite the bullet and make those modifications, but add a kernel/module parameter (e.g., omap2_mcspi.chmode=X) to dynamically select between the various pin configurations. I figured being able to specify the pin assignments from U-Boot would have been sufficiently flexible.

    However, I'm relatively new to the OMAP world, and therefore not familiar with the breadth of devices that this driver is currently supporting. As such, I wasn't sure if this modification would be an "acceptable" patch that one could push upstream to the Linux devs, considering that I haven't put ample time looking into:

    1. (Reverse) compatibility with non-DM8148 devices
    2. That such a change would remain consistent with any existing OMAP2 parameter paradigm
    3. The current state of the OMAP2 code in the mainline kernel, and whether other TI devs have already pushed a similar change upstream

    I would appreciate any thoughts on this that you'd like to offer. 

    Thanks,

    Jon

  • 0 in reply to Jon S.
    Intellectual 360 points

    Hello Jon, Hello Joseph,

    the correct way to do that is as below.

           l &= ~(OMAP2_MCSPI_CHCONF_DPE0);
            l |= (OMAP2_MCSPI_CHCONF_IS | OMAP2_MCSPI_CHCONF_DPE1);

    Br,

    KP

    karunesh.ind@gmail.com