• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 3320 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.

Linux/AM5708: MMC throughput with WiFi module

Andre Hoffard
Prodigy 40 points
Part Number: AM5708

Tool/software: Linux

Hello,

We have a custom board based on am5708 processor interfacing with u-blox LILY-W1 Wi-Fi module (based on the Marvell Avastar 88W8801 chipset) using mmc3 (SDIO) interface. We are able to successfully connect with router but we are facing performance issue which seems to be related to mmc interface configuration.  

We managed to get throughput datarate (tcp connection) in the system of about 10 Mbit/s maximum using iperf tool we were expect to have much higher datarates.

We configure the mmc interface through device tree using clock and bus width settings according both AM5708 Technical Reference Manual (SPRUHZ7E–August 2015–Revised February 2017) and U-Blox system integration manual.

U-Blox module supports 1-bit and 4-bit SDIO transfer modes at the full clock range of 0 to 50 MHz.

MMC3 host controller (AM5708) can be configured (according TRM) 

- DS mode (3.3V IOs): up to 12 MBps (24 MHz clock)
- HS mode (3.3V IOs): up to 24 MBps (48 MHz clock)

- Default SD mode 1-bit data transfer up to 24Mbps (3MBps)

We observe best performance (~ 10 Mbits/s) with MMC3 host controller configured with clock 24 Mhz and bus width 1-bit mode.

Our expectation is to have best performance with MMC3 host controller configured with 48 Mhz clock and 4 bits bus width but then the througput drops down to ~ 6 Mbit/s....

NOTE:

We have checked RF quality and schematic / board design of the u-blox module against the evaluation board of the Lily-W1 module we use for tests as well. RF link is comparible with the reference board.

With this evalution module we can reach bitrates of ~30 Mbit/s using the USB interface to our custom board.

Question is:

Can someone give us directions / guidelines how the mmc interface shall be configured and verified for correct settings.?

--------------------------------------- Config details and results -------------------------------------------------------

&mmc3 {

pinctrl-names = "default", "hs";
pinctrl-0 = <&mmc3_pins_default>;
pinctrl-1 = <&mmc3_pins_hs>;

max-frequency = <48000000>;
ti,non-removable;
ti,dual-volt;
disable-wp;
bus-width = <4>;
/delete-property/ sd-uhs-sdr50;
/delete-property/ sd-uhs-sdr25;
/delete-property/ sd-uhs-sdr12;
};


root@wa55-proto-a:~# cat /sys/kernel/debug/mmc2/ios
clock: 48000000 Hz
vdd: 21 (3.3 ~ 3.4 V)
bus mode: 2 (push-pull)
chip select: 0 (don't care)
power mode: 2 (on)
bus width: 2 (4 bits)
timing spec: 2 (sd high-speed)
signal voltage: 0 (3.30 V)
driver type: 0 (driver type B)

root@wa55-proto-a:~# iperf -c 192.168.5.100
------------------------------------------------------------
Client connecting to 192.168.5.100, TCP port 5001
TCP window size: 43.8 KByte (default)
--------[ 712.298841] Send addba: TID 0
[ 712.306063] Send addba RA:
[ 712.308901] 64 d1 a3 32 fe da
[ 712.312103] wlan0: QUEUE_CMD: cmd=0xce is queued
------------------------------------------------[ 712.317641] wlan0: ----
DNLD_CMD (1493043712.129249): 0xce, act 0x6400, len 22, seqno 0x37
[ 712.329928] DNLD_CMD:
[ 712.332310] ce 00 16 00 37 00 00 00 00 64 d1 a3 32 fe da 01
[ 712.338246] 02 08 ff ff a3 dd
[ 3] local 192.168.5.101 port 44564 connected with 192.168.5.100 port 5001
[ 712.358906] CMD_RESP:
[ 712.361294] ce 80 18 00 37 00 00 00 00 64 d1 a3 32 fe da 01
[ 712.367235] 00 00 02 08 00 00 00 00
[ 712.371040] wlan0: CMD_RESP (1493043712.182649): 0x80ce, result 0, len 24, seqno 0x37
[ 712.379286] ADDBA REQ: 64:XX:XX:XX:fe:da tid=0 ssn=0 win_size=32,amsdu=0
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 7.50 MBytes 6.29 Mbits/sec

================================ TEST 2 =======================================
&mmc3 {

pinctrl-names = "default";
/*pinctrl-0 = <&mmc3_pins_default>; */
pinctrl-0 = <&mmc3_pins_hs>;

max-frequency = <24000000>;
non-removable;
ti,dual-volt;
disable-wp;
bus-width = <1>;
/delete-property/ sd-uhs-sdr50;
/delete-property/ sd-uhs-sdr25;
/delete-property/ sd-uhs-sdr12;
};

root@wa55-proto-a:~# cat /sys/kernel/debug/mmc2/ios
clock: 24000000 Hz
vdd: 21 (3.3 ~ 3.4 V)
bus mode: 2 (push-pull)
chip select: 0 (don't care)
power mode: 2 (on)
bus width: 0 (1 bits)
timing spec: 0 (legacy)
signal voltage: 0 (3.30 V)
driver type: 0 (driver type B)

[ ID] Interval Transfer Bandwidth
[ 3] 0.0-15.0 sec 16.8 MBytes 9.36 Mbits/sec
root@wa55-proto-a:~# iperf -c 192.168.5.100 -t 15
------------------------------------------------------------
Client connecting to 192.168.5.100, TCP port 5001
TCP window size: 43.8 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.5.101 port 43956 connected with 192.168.5.100 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-15.0 sec 17.2 MBytes 9.64 Mbits/sec

Thanks,

Andre Hoffard

  • 0
    TI__Guru**** 393215 points
    The software team have been notified. They will respond here.
  • 0 in reply to Biser Gatchev-XID
    TI__Genius 15510 points

    Are you using in-band interrupts or polling?

    Steve K.

  • 0 in reply to Steve Kipisz
    Prodigy 40 points

    Hi Steve,

    Could you give direction where/how to verify this? I.e. do you refer to the SDIO host controller?

    In 1-bit mode u-blox module utilizes data line 1 (D1) as interrupt line as you can see in attached  picture. 

    What we do observe in this context is that we have huge amount of intrerrupt from mmc2 in /proc/interrupts. 

    kdsdioirqd/mmc2  when running top.We see in register overview sdio_irq_mode: polling

    50Mhz clock 1-bit mode

    kind regards,

    Andre Hoffard

    and kdsdioirqd/mmc2  when running top.

  • 0 in reply to Steve Kipisz
    Prodigy 40 points

    Hi,

    Could you provide us with information how mmc3.dat1 is supposed to be configured in device tree to enable in-band interrupt for SDIO.? 

    Kind regards,

    Andre Hoffard

  • 0 in reply to Andre Hoffard
    Prodigy 130 points
    the SDIO host is configured in polling mode. We have observed performance impact during that mode also for the am335x based reference board with our module. Currently we try to update the device tree to ahve inband interrupt activated. Unfortunately the Ti PinMux tool does not provide any indication when I do chose SDIO4-Bit
    Any help would be appreciated, e.g and example reference board you could delegate us to.

    &mmc3 {
    status = "okay";
    pinctrl-names = "default", "idle";
    pinctrl-0 = <&mmc3_pins_default>;
    pinctrl-1 = <&mmc3_pins_idle>;
    vmmc-supply = <&vdd_3v3>;
    interrupts = <unclear> ?????
    interrupts-parent = <&unclear> ?????
    bus-width = <4>;
    };

    mmc3_pins_idle: pinmux_mmc3_pins_idle {
    pinctrl-single,pins = <
    DRA7XX_CORE_IOPAD(0x3788, PIN_INPUT | MUX_MODE14) /* mmc3_dat1.mmc3_dat1 */
    >;
    };
  • 0 in reply to Soeren Hoeckner
    TI__Genius 15510 points
    For am335x, look at Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt. There is an example for in-band interrupts at the bottom.

    For am57xx, try doing something similar. You do not have to do anything for interrupts or interrupts-parent. The interrupts default is in dra7.dtsi. But that field will not be used. If you look at Documentation/devicetree/bindings/interrupt-controller/interrupts.txt, it describes the interrupt-extended property.Try this for the am57xx board. I am still doing some research.

    Steve K.
  • 0 in reply to Steve Kipisz
    Prodigy 40 points

    Thanks to Soeren Hoeckner thorough analysis we managed to have improved performance:

    Hello gents,

    well, I'm quite convinced the problem is originated with the SDIO host controller from the your MCU (am5708). The MMC3 slot is reporting the interrupt mode as polling (cat /sys/kernel/mmc2/regs). It has been observed also on the am335x a significant performance impact in that mode. Therefore the mmc host controller needs to remux the data_1 pin to a GPIO triggered interrupt, as specified in the SDIO specification. From our point of view does the module operate inside its specified parameters. By the way, this observed issue located on your SDIO host controller driver is affecting all SDIO devices.

     

    After an deep analysis of the omap_hsmmc.c host controller driver implementation, specific device-tree entries seem to be necessary to activate the inband interrupt handling [1]. The so called wake_irq is specified as second interrupt [2]. Without that the controller implementation falls back to polling [3]. Moreover the MCU capabilities are determined to identify whether to use the GPIO as wakeup source [4]. This matches your MCU (OMAP_HSMMC_SWAKEUP_MISSING) [5], if I'm not mistaken. It follows the look up for the muxing pins "default" and "idle", which needs to be defined in the device_tree as well or the driver falls back to polling [6,7].

     Below I have attached the MCU configuration that enabled the interrupt mode for the your SDIO host controller, implemented via omap-hsmmc. 

    [1] http://elixir.free-electrons.com/linux/v4.4.32/source/drivers/mmc/host/omap_hsmmc.c#L2194

    [2] http://elixir.free-electrons.com/linux/v4.4.32/source/drivers/mmc/host/omap_hsmmc.c#L2069

    [3] http://elixir.free-electrons.com/linux/v4.4.32/source/drivers/mmc/host/omap_hsmmc.c#L1764

    [4] http://elixir.free-electrons.com/linux/v4.4.32/source/drivers/mmc/host/omap_hsmmc.c#L1777

    [5] http://elixir.free-electrons.com/linux/v4.4.32/source/drivers/mmc/host/omap_hsmmc.c#L1934

    [6] http://elixir.free-electrons.com/linux/v4.4.32/source/drivers/mmc/host/omap_hsmmc.c#L1783

    [7] http://elixir.free-electrons.com/linux/v4.4.32/source/drivers/mmc/host/omap_hsmmc.c#L1790

     

    attached device-tree necessities for interrupt mode:

     

        mmc3_pins_default: pinmux_mmc3_pins_default {

            pinctrl-single,pins = <

                DRA7XX_CORE_IOPAD(0x377c, PIN_INPUT_PULLUP | MUX_MODE0)     /* mmc3_clk.mmc3_clk */

                DRA7XX_CORE_IOPAD(0x3780, PIN_INPUT_PULLUP | MUX_MODE0)     /* mmc3_cmd.mmc3_cmd */

                DRA7XX_CORE_IOPAD(0x3784, PIN_INPUT_PULLUP | MUX_MODE0)     /* mmc3_dat0.mmc3_dat0 */

                DRA7XX_CORE_IOPAD(0x3788, PIN_INPUT_PULLUP | MUX_MODE0)     /* mmc3_dat1.mmc3_dat1 */

                DRA7XX_CORE_IOPAD(0x378c, PIN_INPUT_PULLUP | MUX_MODE0)     /* mmc3_dat2.mmc3_dat2 */

                DRA7XX_CORE_IOPAD(0x3790, PIN_INPUT_PULLUP | MUX_MODE0)     /* mmc3_dat3.mmc3_dat3 */

            >;

        };

     

        mmc3_pins_idle: pinmux_mmc3_pins_idle {

            pinctrl-single,pins = <

                DRA7XX_CORE_IOPAD(0x3788, PIN_INPUT_PULLUP | WAKEUP_EN | MUX_MODE14)     /* mmc3_dat1.gpio7_0 */

            >;

        };

     

    &mmc3 {

        status = "okay";

     

               compatible = "ti,dra7-hsmmc";

     

        pinctrl-names = "default", "hs", "idle" ;

        pinctrl-0 = <&mmc3_pins_default>;

        pinctrl-1 = <&mmc3_pins_hs>;

        pinctrl-2 = <&mmc3_pins_idle>;

     

        vmmc-supply = <&vdd_3v3>;

        bus-width = <4>;

        keep-power-in-suspend;

        ti,non-removable;

     

               interrupts-extended = <&crossbar_mpu GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>,

                                       <&gpio7 0 IRQ_TYPE_LEVEL_LOW>;

     

    };