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.

Linux/AM4378: Spidev does not output on pins

Part Number: AM4378
Other Parts Discussed in Thread: AM4372

Tool/software: Linux

Hi Everybody!

I recently got my spidev devices registered in /dev (see here for details). 

My devices don't seem to work unfortunately.  I have only scoped out spidev1.1 so far.  I can open the device.  When I configre it I do get messages complaining about not using DMA (see below).  And then I get a TXS timed out message.

I am using a program really similar to this one.  I just added a ton of printing and slowed things down so that I could tell which actions were causing the system log messages.

Here is the output.

root@am437x-evm:/ace/bin# ./helloSpi -C 301
helloSpi ...
    ...Options selected
        device = /dev/spidev1.1
        speed = 24000000
        delay = 0
        bits = 8
        mode = 0x04
    ...Creating device
    ...Setting SPI option
    ...Opening file handle
    ...Committing options     <-- 3 ioctl calls in here
[62332.673461] spidev spi1.1: not using DMA for McSPI (-19)
[62332.678907] spidev spi1.1: not using DMA for McSPI (-19)
[62332.689027] spidev spi1.1: not using DMA for McSPI (-19)
    ...Setting up data transfer
        TX = 0x03 0x01 0x00 0x00 0x00 0x00 0x00 0x00
        RX = 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
    ...Performing ioctl data transfer   <-- 1 ioctl call in here
[62340.712144] spidev spi1.1: TXS timed out
    ...Receive buffer
        RX = 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Good bye!

I had our electrical team scope the clk, miso, mosi, and cs pin for spidex1.1 and there is no activity.

I also see the cs pin held low the entire time.  I think it should only go low when the spi master wants to send data to or retrieve data from that particular device.

Here is my pin mux...

spi2_internal_pins_default: spi2_internal_pins_default {
    pinctrl-single,pins = <
        0x260 ( PIN_OUTPUT | INPUT_EN | MUX_MODE0 ) /* (N20) spi2_sclk.spi2_sclk */
        0x264 ( PIN_OUTPUT | MUX_MODE0 )            /* (P22) spi2_d0.spi2_d0 */
        0x268 ( PIN_INPUT_PULLUP | MUX_MODE0 )      /* (P20) spi2_d1.spi2_d1 */
        0x1b0 ( PIN_OUTPUT | MUX_MODE4 )            /* (AE17) cam0_hd.spi2_cs1 */
        0x1c4 ( PIN_OUTPUT | MUX_MODE4 )            /* (AB19) cam0_data8.spi2_cs2 */
    >;

}

&spi2 {
    compatible = "ti,omap2-mcspi";
    pinctrl-names = "default";
    pinctrl-0 = <&spi2_internal_pins_default>;
    status = "okay";

        ti,spi-num-cs = <4>;
        ti,pindir-d0-out-d1-in = <1>;

ksz8895@1 {
    compatible = "rohm,dh2228fv";
    spi-max-frequency = <100000>;
    reg = <0x1>;
    status = "okay";
    #address-cells = <1>;
    #size-cells = <0>;
};
ksz8895@2 {
    compatible = "rohm,dh2228fv";
    spi-max-frequency = <100000>;
    reg = <0x2>;
    status = "okay";
    #address-cells = <1>;
    #size-cells = <0>;
};

};

Here are (what I think are pertinent) defconfig settings. In fact here's everything SPI related.  I highlighted the ones I think actually matter

root@am437x-evm:/ace/bin# cat /proc/config.gz|gunzip|grep SPI|grep \# -v|grep SPIN -v
CONFIG_REGMAP_SPI=y
CONFIG_MTD_SPI_NOR=y
CONFIG_SPI_CADENCE_QUADSPI=y
CONFIG_WLCORE_SPI=m
CONFIG_INPUT_ADXL34X_SPI=m
CONFIG_SPI=y
CONFIG_SPI_MASTER=y
CONFIG_SPI_BITBANG=m
CONFIG_SPI_GPIO=m
CONFIG_SPI_OMAP24XX=y
CONFIG_SPI_TI_QSPI=y
CONFIG_SPI_SPIDEV=y
CONFIG_SND_SOC_I2C_AND_SPI=y
CONFIG_RTC_I2C_AND_SPI=y

I've seen various posts about differing pinmux settings.  I've seen Biser say the clk needs to be an input (I tried, no change), I've seen another post that said they had success with clk as output with input_en flag.  So I'm not sure what is the "right" answer. 

All thoughts/suggestions/troubleshooting tips are welcome.

Thanks in advance!

Nathan

  • Hi,

    Which SDK are you using?

    Best Regards,
    Yordan
  • Looking at am43xx.h it appears output & input_en is the same thing as input...

    #define PIN_OUTPUT (PULL_DISABLE)

    #define PIN_INPUT (INPUT_EN | PULL_DISABLE)

    ...so both are the right answer.

  • Hi,

    Try these settings for enabling the SPI:
    e2e.ti.com/.../2321156

    The post is for am335x, but the general pinmux settings (only register addresses and muxmodes may differ) & SPI settings are the same for all Sitara devices.

    Best Regards,
    Yordan
  • Hi Yordan,

    Thanks for your help.  I tried the settings in the post you referenced and I have made incremental progress.  The chip select lines are now high when inactive.   I still do not see any activity on the SPI bus when attempting a read of the slave device.

    dts state now...

    spi2_internal_pins_default: spi2_internal_pins_default {

    pinctrl-single,pins = <

    0x260 ( PIN_INPUT | MUX_MODE0 ) /* (N20) spi2_sclk.spi2_sclk */

    0x264 ( PIN_OUTPUT | MUX_MODE0 ) /* (P22) spi2_d0.spi2_d0 */

    0x268 ( PIN_INPUT | MUX_MODE0 ) /* (P20) spi2_d1.spi2_d1 */

    0x1b0 ( PIN_OUTPUT | MUX_MODE4 ) /* (AE17) cam0_hd.spi2_cs1 */

    0x1c4 ( PIN_OUTPUT | MUX_MODE4 ) /* (AB19) cam0_data8.spi2_cs2 */

    >;

    };

    &spi2 {

    compatible = "ti,omap2-mcspi";

    pinctrl-names = "default";

    pinctrl-0 = <&spi2_internal_pins_default>;

    status = "okay";

    ti,spi-num-cs = <4>;

    ti,pindir-d0-out-d1-in = <1>;

    ksz8895@1 {

    compatible = "rohm,dh2228fv";

    spi-max-frequency = <100000>;

    reg = <0x1>;

    status = "okay";

    #address-cells = <1>;

    #size-cells = <0>;

    spi-cs-high;

    };

    ksz8895@2 {

    compatible = "rohm,dh2228fv";

    spi-max-frequency = <100000>;

    reg = <0x2>;

    status = "okay";

    #address-cells = <1>;

    #size-cells = <0>;

    spi-cs-high;

    };

    };

    Interestingly, I do see a spurt of traffic on start up.  I think u-boot might be probing it, and then perhaps the kernel does aswell?  Could there be some other driver getting in the way of spidev?

  • Hi Nathan,
    I was working on AM335X SPI three years back. I had to configure SPI CLK as INPUT to get SPI to working state. Check whether this works for you. Also check whether your MOSI and MISO lines are configured correctly. Find out if there is any restriction on MOSI and MISO to be configured in particular way.

    Regards,
    Gangadhar

  • Hi,

    I just noticed the following:
    ksz8895@1 {
    compatible = "rohm,dh2228fv";
    ksz8895@2 {
    compatible = "rohm,dh2228fv";
    KSZ8895 are network devices, that are NOT supported by the spidev driver (rohm,dh2228fv). You should connect them to MII/RMII interface.

    Also for debug purposes can you try to read the pinmux registers with devmem2 to see if they have the values passed from dts? As a suggestion try adding the pinmux configurations in u-boot as well. In latest SDKs pinmux is done in u-boot.

    Best Regards,
    Yordan
  • Thanks Yordan,

    We are not using the SPI interface to these switches for network traffic.  We simply intend to configure them and gather port statistics and such.  I think the spidev driver will work for this.  I'm simply implementing table 4-1 of this datasheet.

    On devmem2, what memory address should I be reading?  I tried reading spi2 address from am4372.dtsi (0x481a2000) but devmem2 core dumped.  Here is the output...

    root@am437x-evm:~# devmem2 0x481a2000
    /dev/mem opened.[61703.934441] Unhandled fault: external abort on non-linefetch (0x1018) at 0xb6f2f000
    [61703.943222] pgd = ed628000
    [61703.945950] [b6f2f000] *pgd=fc99f831
    [61703.949715] ------------[ cut here ]------------
    [61703.954406] WARNING: CPU: 0 PID: 810 at drivers/bus/omap_l3_noc.c:147 l3_interrupt_handler+0x25c/0x36c
    [61703.963773] 44000000.ocp:L3 Custom Error: MASTER M2 (64-bit) TARGET L4_PER_0 (Read): Data Access in User mode during Functional access
    [61703.975917] Modules linked in: bc_example(O) xhci_plat_hcd xhci_hcd usbcore dwc3 udc_core usb_common ti_am335x_adc sha512_generic sha512_arm s)
    [61704.023348] CPU: 0 PID: 810 Comm: devmem2 Tainted: G W O 4.9.28-geed43d1050 #24
    [61704.031659] Hardware name: Generic AM43 (Flattened Device Tree)
    [61704.037611] Backtrace:
    [61704.040129] [<c010b7d0>] (dump_backtrace) from [<c010ba8c>] (show_stack+0x18/0x1c)
    [61704.047754] r7:00000009 r6:00000000 r5:c09b3204 r4:edd43c58
    [61704.053469] [<c010ba74>] (show_stack) from [<c03c0f18>] (dump_stack+0x24/0x28)
    [61704.060747] [<c03c0ef4>] (dump_stack) from [<c012d370>] (__warn+0xe8/0x100)
    [61704.067758] [<c012d288>] (__warn) from [<c012d3c8>] (warn_slowpath_fmt+0x40/0x48)
    [61704.075297] r9:00000000 r8:ee914cd0 r7:c09b32dc r6:00000002 r5:c09b3130 r4:c09b31d4
    [61704.083099] [<c012d38c>] (warn_slowpath_fmt) from [<c03f0128>] (l3_interrupt_handler+0x25c/0x36c)
    [61704.092023] r3:ee914b00 r2:c09b31d4
    [61704.095622] r4:80080003
    [61704.098197] [<c03efecc>] (l3_interrupt_handler) from [<c016aa28>] (__handle_irq_event_percpu+0xb4/0x144)
    [61704.107742] r10:c0c179c8 r9:ee81db00 r8:00000015 r7:edd43d7c r6:00000000 r5:ee81db00
    [61704.115614] r4:ee919080
    [61704.118181] [<c016a974>] (__handle_irq_event_percpu) from [<c016aadc>] (handle_irq_event_percpu+0x24/0x60)
    [61704.127901] r10:be904ad8 r9:edd42000 r8:ee808000 r7:edd43f40 r6:00000000 r5:ee81db00
    [61704.135773] r4:ee81db00
    [61704.138339] [<c016aab8>] (handle_irq_event_percpu) from [<c016ab7c>] (handle_irq_event+0x64/0x90)
    [61704.147260] r5:c0c082a0 r4:ee81db00
    [61704.150878] [<c016ab18>] (handle_irq_event) from [<c016de28>] (handle_fasteoi_irq+0xc0/0x200)
    [61704.159452] r5:c0c082a0 r4:ee81db00
    [61704.163066] [<c016dd68>] (handle_fasteoi_irq) from [<c0169c10>] (generic_handle_irq+0x2c/0x3c)
    [61704.171735] r7:edd43f40 r6:00000000 r5:00000015 r4:c0c1f56c
    [61704.177439] [<c0169be4>] (generic_handle_irq) from [<c016a2cc>] (__handle_domain_irq+0x5c/0xb0)
    [61704.186197] [<c016a270>] (__handle_domain_irq) from [<c0101520>] (gic_handle_irq+0x40/0x6c)
    [61704.194608] r9:edd42000 r8:fa241100 r7:fa240100 r6:edd43e30 r5:fa24010c r4:c0c02c14
    [61704.202405] [<c01014e0>] (gic_handle_irq) from [<c010c58c>] (__irq_svc+0x6c/0xa8)
    [61704.209929] Exception stack(0xedd43e30 to 0xedd43e78)
    [61704.215019] 3e20: 00404100 00000100 c0c49940 00000000
    [61704.223256] 3e40: 00000202 00000012 00000000 00000000 ee808000 edd42000 be904ad8 edd43edc
    [61704.231487] 3e60: c0c49980 edd43e80 c0131048 c0130b10 600e0113 ffffffff
    [61704.238154] r9:edd42000 r8:ee808000 r7:edd43e64 r6:ffffffff r5:600e0113 r4:c0130b10
    [61704.245957] [<c0130a78>] (__do_softirq) from [<c0131048>] (irq_exit+0x140/0x144)
    [61704.253408] r10:be904ad8 r9:edd42000 r8:ee808000 r7:00000000 r6:00000000 r5:00000012
    [61704.261280] r4:c0c1f56c
    [61704.263845] [<c0130f08>] (irq_exit) from [<c016a2d0>] (__handle_domain_irq+0x60/0xb0)
    [61704.271730] [<c016a270>] (__handle_domain_irq) from [<c0101520>] (gic_handle_irq+0x40/0x6c)
    [61704.280142] r9:edd42000 r8:fa241100 r7:fa240100 r6:edd43f40 r5:fa24010c r4:c0c02c14
    [61704.287937] [<c01014e0>] (gic_handle_irq) from [<c010c58c>] (__irq_svc+0x6c/0xa8)
    [61704.295461] Exception stack(0xedd43f40 to 0xedd43f88)
    [61704.300556] 3f40: edd43fb0 00000001 00000000 600e0010 edd42000 00000000 edd43fb0 10c53c7d
    [61704.308791] 3f60: 00000000 edd42000 be904ad8 edd43fac edd43fb0 edd43f90 c0107d14 c010b3b8
    [61704.317014] 3f80: 600e0113 ffffffff
    [61704.320540] r9:edd42000 r8:00000000 r7:edd43f74 r6:ffffffff r5:600e0113 r4:c010b3b8
    [61704.328349] [<c010b368>] (do_work_pending) from [<c0107d14>] (slow_work_pending+0xc/0x20)
    [61704.336582] r7:10c53c7d r6:ffffffff r5:600e0010 r4:00010744
    [61704.342273] ---[ end trace 9394231af9932575 ]---

    Memory mapped at address 0xb6f2f000.
    Bus error (core dumped)

    Thanks,

    Nathan

  • Ok, this kernel panic is expected for some kernels/devices. In most of the cases pinmux register addresses are protected and cannot be accessed from user space. Sorry for misleading you on this one.

    Let me dig in further into this. I'll update as soon as I have anything.

    Best Regards,
    Yordan
  • Hello Nathan,

    TI Linux forum is going to be closed this week. In the future please use the device forum for Linux related questions on a particular device. I have moved your thread over to Sitara forum. Thank you!

    best regards,
    David Zhou
  • Hi Yordan,

    I added the related items to the u-boot dts and nothing changed. I get mosi and clk on startup briefly, then never again.

    Nathan
  • Are there any registers I could inspect with the XDS2xx debugger? I'd like to confirm that the traces I'm connected to really are connected to the pinpads I think they are connectd to. If I can confirm they are, then we can be sure it is a pinmuxing/linux/issue.

    Any help would be greatly appreciated.
    Nathan
  • Hi,

    You can dump the corresponding SPI pinmux settings:
    CTRL_CONF_CAM0_HD 9B0 ===> muxmode4 => spi2_cs1
    CTRL_CONF_CAM0_VD 9B4 ===> I think this should be CTRL_CONF_CAM0_PCLK 9C0 (offset in dts 1C0) MUX_MODE4 => spi2_cs0 Curretnly CTRL_CONF_CAM0_HD (offsett in dts 1B0) is set to MUX_MODE4 => spi2_d0, so you're missing cs0.
    CTRL_CONF_SPI2_SCLK A60 ===> clk
    CTRL_CONF_SPI2_D0 A64 ===> d0
    CTRL_CONF_SPI2_D1 A68 ===> d1

    Best Regards,
    Yordan
  • Hi Yordan,

    I did not realize you could not skip a chip select line.  I have a pin available that goes no where.  I configured it like this...

    spi2_internal_pins_default: spi2_internal_pins_default {
        pinctrl-single,pins = <
            0x260 ( PIN_INPUT | MUX_MODE0 ) /* (N20) spi2_sclk.spi2_sclk */
            0x264 ( PIN_OUTPUT | MUX_MODE0 ) /* (P22) spi2_d0.spi2_d0 */
            0x268 ( PIN_INPUT | MUX_MODE0 ) /* (P20) spi2_d1.spi2_d1 */
            0x1c0 ( PIN_OUTPUT | MUX_MODE4 ) /* (AC20) cam0_pclk.spi2_cs0 */   <- New CS0 pin to nowhere
            0x1b0 ( PIN_OUTPUT | MUX_MODE4 ) /* (AE17) cam0_hd.spi2_cs1 */
            0x1c4 ( PIN_OUTPUT | MUX_MODE4 ) /* (AB19) cam0_data8.spi2_cs2 */
        >;
    };

    &spi2 {
        compatible = "ti,omap2-mcspi";
        pinctrl-names = "default";
        pinctrl-0 = <&spi2_internal_pins_default>;
        status = "okay";

        ti,spi-num-cs = <3>;
        ti,pindir-d0-out-d1-in = <1>;

        ksz8895@1 {
            compatible = "rohm,dh2228fv";
            spi-max-frequency = <100000>;
            reg = <0x1>;
            status = "okay";
            #address-cells = <1>;
            #size-cells = <0>;
            spi-cs-high;
        };
        ksz8895@2 {
            compatible = "rohm,dh2228fv";
            spi-max-frequency = <100000>;
            reg = <0x2>;
            status = "okay";
            #address-cells = <1>;
            #size-cells = <0>;
            spi-cs-high;
        };
    };

    Rebuilt the dtb and there was no change in the behavior.  No MOSI and no CLK output.

  • Ok. With the settings you have, do you see /dev/spidevX.Y nodes in your filesystem?

    Best Regards,
    Yordan
  • Yes,

    root@am437x-evm:~# ls /dev/spi*
    /dev/spidev1.1 /dev/spidev1.2

    Nathan

  • To confirm I didn't have a board problem. I re-muxed the spi2 pins to be gpio. Then I confirmed I could toggle each pin with sysfs. I do not think there is a problem with the layout of my board.

    Should I try to run spi2 with no chip selects?
  • Hi Yordan,

    Do you have any other thoughts on why SPI doesn't work?

    Thanks,
    Nathan

  • Nathan,

    As I said previously, I have no other explanation except that the ethernet phys ksz8895 are somehow not compatible and don't want to communicate with the spidev driver.

    If you just change your dts as spidev@1 and spidev@2 isntead of  ksz8895@1 and  ksz8895@2,  your board should be working fine, and this should verify that your spi configurations are correct.

    Best Regards,
    Yordan

  • Thanks Yordan,

    I thought that text was an arbitrary label. I have changed the dts to spidev instead of ksz8895. Here is the entry...

    spi2_internal_pins_default: spi2_internal_pins_default {
    pinctrl-single,pins = <
    0x260 ( PIN_INPUT | MUX_MODE0 ) /* (N20) spi2_sclk.spi2_sclk */
    0x264 ( PIN_OUTPUT | MUX_MODE0 ) /* (P22) spi2_d0.spi2_d0 */
    0x268 ( PIN_INPUT | MUX_MODE0 ) /* (P20) spi2_d1.spi2_d1 */
    0x1c0 ( PIN_OUTPUT | MUX_MODE4 ) /* (AC20) cam0_pclk.spi2_cs0 */
    0x1b0 ( PIN_OUTPUT | MUX_MODE4 ) /* (AE17) cam0_hd.spi2_cs1 */
    0x1c4 ( PIN_OUTPUT | MUX_MODE4 ) /* (AB19) cam0_data8.spi2_cs2 */
    >;
    };

    &spi2 {
    compatible = "ti,omap2-mcspi";
    pinctrl-names = "default";
    pinctrl-0 = <&spi2_internal_pins_default>;
    status = "okay";

    ti,spi-num-cs = <3>;
    ti,pindir-d0-out-d1-in = <1>;

    spidev@1 {
    compatible = "rohm,dh2228fv";
    spi-max-frequency = <100000>;
    reg = <0x1>;
    status = "okay";
    #address-cells = <1>;
    #size-cells = <0>;
    spi-cs-high;
    };
    spidev@2 {
    compatible = "rohm,dh2228fv";
    spi-max-frequency = <100000>;
    reg = <0x2>;
    status = "okay";
    #address-cells = <1>;
    #size-cells = <0>;
    spi-cs-high;
    };
    };

    ... as you can see I have three contiguous chip selects in use as you recommended. I still get the same results.

    I get these when I try to configure the SPI...

    [ 9935.293689] spidev spi1.2: not using DMA for McSPI (-19)
    [ 9935.299140] spidev spi1.2: not using DMA for McSPI (-19)
    [ 9935.309422] spidev spi1.2: not using DMA for McSPI (-19)

    ... are these errors benign?

    I get this when I try to transfer data...

    [ 9943.333015] spidev spi1.2: TXS timed out 2

    I added the "2" to the driver since there are many "TXS timed out" messages in the driver. This one is inside omap2_mcspi_txrx_pio at line 729.
  • Found something...

    [ 9935.309422] spidev spi1.2: not using DMA for McSPI (-19)

    .. appear to be benign. It is a warning that the transfer is so small it will use PIO instead of DMA.
  • Hi Yordan,

    You said "In latest SDKs pinmux is done in u-boot. "  Can you expound on that?  My u-boot dts is relatively unchanged from am437x-gp-evm.  I made my customizations in board-support/linux.../dts.  Only changing the dts in board-support/linux... has seemed to work so far for me. 

    Are these related?  Is one dts file have precedence over the other?

    Thanks,

    Nathan

  • Nathan,

    Kernel dts should overwrite the settings. Here is what I did on my BBB (I don't have my hands on AM437x board at the moment), however kernel settings should be the same on AM437x, with the exception of the pinmux of course:

            spi1_pins: spi1_pins {

                   pinctrl-single,pins = <

                           AM33XX_IOPAD(0x990, PIN_INPUT_PULLUP | MUX_MODE3) /*mcasp0_aclkx.spi1_sclk*/

                           AM33XX_IOPAD(0x99c, PIN_INPUT | MUX_MODE3) /*mcasp0_ahclkr.spi1_cs0*/

                           AM33XX_IOPAD(0x994, PIN_INPUT | MUX_MODE3) /* mcasp0_fsx.spi1_d0*/

                           AM33XX_IOPAD(0x998, PIN_INPUT | MUX_MODE3) /*mcasp0_axr2.spi1_d1*/

                   >;

          };

      &spi1 {

      status="okay";

      pinctrl-names = "default";

      pinctrl-0 = <&spi1_pins>;

      spidev@0 {

            compatible = "rohm,dh2228fv";

            spi-max-frequency = <5000000>;

            reg = <0>;

            status = "okay";

      };

    };

    Perhaps I wasn't clear enough there is no requirement to always have cs0 configured. You can use just cs1 and cs2, if you don't need cs0.

    With the above settings I execute root@am335x-evm:~# echo "BABACECA" > /dev/spidev1.0 in the user space and I get the following scope waveforms:

    As you can see the SPI interface is working fine. 

    Best Regards, 
    Yordan

  • Yordan and Nathan,

    I have been doing some experimenting on this as well. So I was able to replicate the pinmux settings Yordan used on my BBB, and I think we can all agree that if the pinmux is set correctly, the device will behave as configured.

    I have also had success getting multiple chip selects working on the same SPI peripheral. In essence I added an additional chip select (D17) to the spi1_pins:

    spi1_pins: spi1_pins {

    pinctrl-single,pins = <

    AM33XX_IOPAD(0x990, PIN_INPUT_PULLUP | MUX_MODE3) /*mcasp0_aclkx.spi1_sclk*/

    AM33XX_IOPAD(0x99c, PIN_INPUT | MUX_MODE3) /*mcasp0_ahclkr.spi1_cs0*/

    AM33XX_IOPAD(0x97C,PIN_INPUT|MUX_MODE4) /*uart1_rtsn.spi1_cs0*/

    AM33XX_IOPAD(0x994, PIN_INPUT | MUX_MODE3) /* mcasp0_fsx.spi1_d0*/

    AM33XX_IOPAD(0x998, PIN_INPUT | MUX_MODE3) /*mcasp0_axr2.spi1_d1*/

    >;

    };

    Note that this pin (D17) is also used as an I2C pin to read the EEPROMS on BBB capes. I commented this out to avoid creating any confusion as to what the pin was used for, and disabled the i2c2 entry just in case.

    Then I redefined spi1 as:

    &spi1 {

    status="okay";

    pinctrl-names = "default";

    pinctrl-0 = <&spi1_pins>;

    ti,spi-num-cs=<2> /* I'm not sure if this is strictly necessary, but I haven't tried removing*/

    spidev@0 {

    compatible = "rohm,dh2228fv";

    spi-max-frequency = <5000000>;

    reg = <0>;

    status = "okay";

    };

    spidev@1 {

    compatible = "rohm,dh2228fv";

    spi-max-frequency = <5000000>;

    reg = <1>;

    status = "okay";

    };

    };

    I was able to write out data on both /dev/spidev1.0 and /dev/spidev1.1 using this configuration.

    The key difference for me was not using the "compatible="ti,omap2-mcspi;" line. When I did that I was getting the same errors Nathan was seeing with the TX timeouts. 

    Hope this helps!

    Munan

  • Thanks Munan,

    Changing compatible from "ti,omap2-mcspi;" back to "ti,am4372-mcspi","ti,omap4-mcspi"; seems to have resolved the problem. The switch out there even replies now.

    Thanks everyone for your help,
    Nathan