Linux/DRA726: SDIO issue

Hi Michel,

I'm not a linux expert, I'm sorry I'm not sure how those things are set up. Hope you will get the answer soon. For the low-level registers description you can refer to the MMC/SD/SDIO chapter of TRM if you wish.

I'm rather curious why would polling mode affect the bluetooth radio range? I would agree for reduced throughput (in polling mode vs irq) but why range?

Regards,

Stan

Hi Michel,
DRA726 EVM has a dedicated GPIO - GPIO5-7 to serve as an interrupt line for SDIO IRQ so at least on DRA726 EVM it should be not in polling mode.
On older OMAPs some of the boards did not have a dedicated line that's why SDIO was used in polling mode.
Do you have any GPIO line connected to BT device for this purpose?

You may refer to "wlcore" device node under mmc4 in dra7-evm.dts as an example.

look for wake_irq in drivers/mmc/host/omap_hsmmc.c for further information.

Regards,
RK

RK,

The interrupt lines are not connected, the wakeup I have are inputs to the u-blox device, HOST2WL_WAKEUP and HOST2BT_WAKEUP

I would expect the uart interrupt to be used for bluetooth and the mmc3 interrupt used for SDIO

dra7.dtsi

        mmc3: mmc@480ad000 {
            compatible = "ti,dra7-hsmmc", "ti,omap4-hsmmc";
            reg = <0x480ad000 0x400>;
            interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;
            ti,hwmods = "mmc3";
            ti,needs-special-reset;
            dmas = <&sdma_xbar 77>, <&sdma_xbar 78>;
            dma-names = "tx", "rx";
            status = "disabled";
            sd-uhs-sdr12;
            sd-uhs-sdr25;
            sd-uhs-sdr50;
        };

My device tree

       wlan_en: fixedregulator@0 {
            compatible = "regulator-fixed";
            regulator-name = "wlan-en-regulator";
            regulator-min-microvolt = <0x325aa0>;
            regulator-max-microvolt = <0x325aa0>;
            /* wlan_en gpio */
            gpio = <&gpio1 16 GPIO_ACTIVE_HIGH>;
            startup-delay-us = <0x11170>;
            enable-active-high;
    };

        mmc3_pins_default: pinmux_mmc3_pins_default {
                pinctrl-single,pins = <
            0x37c (PIN_INPUT_PULLUP | MUX_MODE0) /* mmc3_clk.mmc3_clk */
            0x380 (PIN_INPUT_PULLUP | MUX_MODE0) /* mmc3_cmd.mmc3_cmd */
            0x384 (PIN_INPUT_PULLUP | MUX_MODE0) /* mmc3_dat0.mmc3_dat0 */
            0x388 (PIN_INPUT_PULLUP | MUX_MODE0) /* mmc3_dat1.mmc3_dat1 */
            0x38c (PIN_INPUT_PULLUP | MUX_MODE0) /* mmc3_dat2.mmc3_dat2 */
            0x390 (PIN_INPUT_PULLUP | MUX_MODE0) /* mmc3_dat3.mmc3_dat3 */
                >;
        };

&mmc3 {
        status = "okay";
        pinctrl-names = "default";
        pinctrl-0 = <&mmc3_pins_default>;

        max-frequency = <150000000>;
        ti,non-removable;
        vmmc-supply = <&wlan_en>;
        disable-wp;
        bus-width = <4>;
        /delete-property/ sd-uhs-sdr50;
        /delete-property/ sd-uhs-sdr25;
        /delete-property/ sd-uhs-sdr12;
};

I have not seen any issue yet with wifi, I did have to replace the wpa_supplicant that TI uses for the linux community version.

I may be proved wrong later but so far it works fine with the wifi TX/RX device about 30 feet away.

SDIO seems to be working fine, u-blox supports SDIO-SDIO for industrial and SDIO-UART for automotive.

I have u-blox module setup to have wifi on SDIO and bluetooth on uart.

So the interrupt problem woudl be on the uart and not SDIO, isn't that right?

u-blox does send commands thru SDIO but the bluetooth communication for the application is done thru UART9

root@actia-global-display:~# cat  /sys/kernel/debug/mmc2/ios
clock:          100000000 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:    0 (legacy)
signal voltage: 0 (3.30 V)
driver type:    0 (driver type B)

root@actia-global-display:~# cat /sys/kernel/debug/mmc2/regs
mmc2:
sdio irq mode   polling
ctx_loss:       1

regs:
CON:            0x00000600
PSTATE:         0x01f00000
HCTL:           0x00000f02
SYSCTL:         0x000d0047
IE:             0x00000000
ISE:            0x00000000
CAPA:           0x21e10080

root@actia-global-display:~# cat /proc/interrupts       
           CPU0       
 16:          0      CBAR  32 Level     gp_timer
 17:          0       GIC  29 Edge      arch_timer
 18:      36366       GIC  30 Edge      arch_timer
 22:          0      CBAR   4 Level     l3-dbg-irq
 23:          0     WUGEN  10 Level     l3-app-irq
 25:          1      CBAR 121 Level     talert
 27:       1179      CBAR   8 Level     omap-dma-engine
 30:        580      CBAR 361 Level     43300000.edma_ccint
 32:          0      CBAR 359 Level     43300000.edma_ccerrint
 35:          0      CBAR  24 Level     4ae10000.gpio
 68:          0      CBAR  25 Level     48055000.gpio
101:          0      CBAR  26 Level     48057000.gpio
134:   18229018      CBAR  27 Level     48059000.gpio
139:   18229018  48059000.gpio   4 Level     egalax_i2c
167:          0      CBAR  28 Level     4805b000.gpio
200:          0      CBAR  29 Level     4805d000.gpio
233:          0      CBAR  30 Level     48051000.gpio
266:          0      CBAR 116 Level     48053000.gpio
301:        689      CBAR  69 Level     48020000.serial
306:          3      CBAR 251 Level     mbox_ipu1_ipc3x
310:         35      CBAR 255 Level     mbox_ipu2_ipc3x
328:          9      CBAR 108 Level     omap_dmm_irq_handler
329:        283      CBAR  16 Level     SGX ISR
331:        332      CBAR  51 Level     48070000.i2c
332:          0      CBAR  56 Level     48060000.i2c
333:          0      CBAR  57 Level     4807a000.i2c
334:        341      CBAR  78 Level     mmc0
335:       4847      CBAR  81 Level     mmc1
336:      45518      CBAR  89 Level     mmc2
337:          0      CBAR 395 Level     58882000.mmu
338:          0      CBAR 396 Level     55082000.mmu
341:          5      CBAR  72 Level     dwc3-omap
342:          5      CBAR  87 Level     dwc3-omap
343:          0      CBAR 149 Level     48464000.mcasp_tx
344:          0      CBAR 148 Level     48464000.mcasp_rx
346:       9912      CBAR 335 Level     48484000.ethernet
347:        123      CBAR 336 Level     48484000.ethernet
349:          0      CBAR 354 Level     vpe
353:         20      CBAR  46 Level     4b101000.sham
354:          0      CBAR  47 Level     48090000.rng
356:      21031      CBAR  20 Level     OMAP DISPC
421:          0      CBAR   2 Edge      tps65917
423:          0   pinctrl 584 Edge      48020000.serial
424:         27      CBAR  71 Level     xhci-hcd:usb1
425:          0      CBAR  73 Level     xhci-hcd:usb3
IPI0:          0  CPU wakeup interrupts
IPI1:          0  Timer broadcast interrupts
IPI2:          0  Rescheduling interrupts
IPI3:          0  Function call interrupts
IPI4:          0  Single function call interrupts
IPI5:          0  CPU stop interrupts
IPI6:          0  IRQ work interrupts
IPI7:          0  completion interrupts
Err:          0

Michel

HI Michel,
If SDIO communication seems to be fine then I'm not sure why you mentioned SDIO issue in your original post.

If Bluetooth communication happens over UART9 then yes the interrupts would happen only on uart.

I don't think the uart controller has any play in the BT range issue. UART controller doesn't even know what's connected device functionality.

- what's the BT device connected to dra726?

I have verified BT functionality over UART3 in the past using TI wIlink 8 combo card and the range was quite good.

Regards,
RK

RK,

The module has both wifi and bluetooth. Initialization is done thru sdio. Two possible driver are used, when the SDIO-UART driver is used communication for bluetooth is switched to the uart.

The device is EMMY-W1 from u-blox

Michel

Hi Michel,
Based on what I learned on the web, the range is a function of the transmitter power which is part of the BT device.
There are different classes for the transmitter.But, even the lowest class should support distance up to 10m as per the article below
www.sans.edu/.../bluetooth

If SDIO is only used during the device configuration then I don't think it has anything to do with the range issue.

You may try a standalone test without connecting to WiFi or BT to see if the UART is the problem or If it's possible try with a different device to see if the same issue exists.

Regards,
RK

RK,

I came to same conclusion as you on that. The uart is working fine, I have a box full of those devices, all identical.
It doesn't seem possible to change the power. When I try to get higher than 4 it tells me that the power is 0 on the next check. It doesn't go back to 4 unless I roboot. What is the range and what would be the way to increase the power level?

I don't have a problem identify a phone that is several meters away so that is just a TX issue on the device. I have an external antenna which works fine with wifi and bluetooth reception.

Regards,
Michel

Michel,
I don't know how the transmitter power can be increased.
What does the vendor say?

Regards,
RK

RK,

They haven't given an answer yet. I will have to ask, u-blox engineer told me that they've asked the part manufacturer for info.

Michel