• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 34 subscribers
  • Views 82 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.

AM62P: I am investigating an SDIO DAT1 interrupt issue on AM62Px.

user6235376
Prodigy 60 points

Part Number: AM62P

Hello TI team,
I am investigating an SDIO DAT1 interrupt issue on AM62Px.
■ Environment
Device: AM62Px
OS: Linux
Interface: SDIO
SDIO slave: Kyocera Orini
Host controller: SDHCI

■ Issue summary
After repeating a reset / reprobe / open sequence for the SDIO device, SDIO DAT1 interrupts sometimes stop being detected by the AM62Px host controller.
For debugging purposes, I added logs in:
sdhci.c
SDHCI_INT_CARD_INT handling
sdio_irq.c
sdio_signal_irq()
sdio_claim_irq()

■ Observations from logs
The following operations succeed correctly:
sdio_claim_irq()
CCCR IENx write/readback
IRQ registration
CCCR IENx is correctly read back as 0x03.
However, in failure cases, SDHCI_INT_CARD_INT is no longer detected.
■ Normal case
The following logs continue repeatedly:
"mmc2: SDIO DAT1 IRQ"
"sdio_signal_irq pending=TRUE"
■ Failure cases
One of the following occurs:
Only 1-2 DAT1 IRQs are detected
No DAT1 IRQ occurs at all after IRQ registration
■ Test sequence
Release slave reset
Reset slave
sdio_open()
Activate sequence
Close SDIO handle
Wait for reprobe / reinitialization
Open again
Configure slave registers
■ Observed pattern
1st run: normal
2nd run: partial failure
3rd run: DAT1 IRQ lost
4th run: normal again
■ Current understanding
Based on the logs:
Linux SDIO IRQ registration itself appears successful
However, DAT1 interrupt detection may be lost inside the SDHCI host controller
Another possibility is an issue related to:
DAT1 line state
pending interrupt handling
timing during reset / reprobe
■ Questions
 
Are there any known issues or timing requirements for SDIO DAT1 interrupt handling on AM62Px?
 
Is there a recommended sequence for:
SDIO reset
reprobe
interrupt re-enable
DAT1 interrupt recovery?
 
Are there any SDHCI registers that should be checked when DAT1 IRQ detection stops? (e.g. INT_STATUS / SIGNAL_ENABLE / PRESENT_STATE)
 
Could this behavior be related to:
SDHCI interrupt latch state
runtime PM
clock gating
DAT1 level detection state machine?
Any advice regarding software-side debugging or recommended recovery handling would be appreciated.

Best regards Izawa

  • 0
    Prodigy 60 points

    Normal case
    [ 771.674714] SDIO: func=1 IENx write=0x03 read=0x03 ret=0
    [ 771.680033] kcits_sdio2: irq registered
    [ 771.680036] mmc2: SDIO DAT1 IRQ
    [ 771.686987] mmc2: sdio_signal_irq pending=TRUE

    [ 775.287046] mmc2: SDIO DAT1 IRQ
    [ 775.290204] mmc2: sdio_signal_irq pending=TRUE
    [ 775.295172] mmc2: SDIO DAT1 IRQ
    [ 775.298313] mmc2: sdio_signal_irq pending=TRUE
    ...

    Partial failure case
    [ 863.474622] SDIO: func=1 IENx write=0x03 read=0x03 ret=0
    [ 863.479948] kcits_sdio2: irq registered
    [ 863.479957] mmc2: SDIO DAT1 IRQ
    [ 863.491331] mmc2: sdio_signal_irq pending=TRUE

    [ 867.094344] mmc2: SDIO DAT1 IRQ
    [ 867.097504] mmc2: sdio_signal_irq pending=TRUE

    (no further DAT1 IRQ detected)

    Complete failure case
    [ 900.228862] SDIO: func=1 IENx write=0x03 read=0x03 ret=0
    [ 900.234178] kcits_sdio2: irq registered

    (no SDIO DAT1 IRQ occurs)

    Based on these logs:

    - SDIO IRQ registration succeeds
    - CCCR IENx configuration succeeds
    - However, SDHCI_INT_CARD_INT detection eventually stops

    This appears to indicate either:
    - a DAT1 interrupt detection issue inside the SDHCI host controller, or
    - a DAT1 line state / pending interrupt handling issue during the reset and reprobe sequence.

  • 0 in reply to user6235376
    TI__Guru* 86081 points

    Hello,

    Do you see the issue with the latest SDK as well?

    Since the issue is sporadic, the issue could very well be caused by hardware.

    • Do you see the issue on a different board with different SDIO card as well?
    • Is the schematics reviewed by TI?

    Thanks!

  • +1 in reply to Prashant Shivhare
    Prodigy 60 points

    Hello Prashant,

    Thank you for your response.

    We are currently using:

    - ti-processor-sdk-linux-rt-am62pxx-evm-11.00.09.04

    The issue is reproducible on our setup after repeating the reset/reprobe/open sequence several times.

    From the current logs:

    - sdio_claim_irq() succeeds
    - CCCR IENx readback is correct (0x03)
    - IRQ registration succeeds
    - However, SDHCI_INT_CARD_INT eventually stops occurring

    At the moment, the issue has only been tested with our Kyocera ITS SDIO module.

    We are planning to check the DAT1 signal waveform on the hardware side soon in order to confirm whether:
    - the DAT1 line itself stops toggling, or
    - the SDHCI host controller stops detecting the interrupt.

    Please let us know if there are any recommended:
    - SDHCI registers to monitor
    - debug methods
    - known timing considerations
    related to SDIO DAT1 interrupt handling on AM62Px.

    Best regards ,

    Izawa

  • +1 in reply to user6235376
    Prodigy 60 points

    Hello Prashant,

    Below is the current device tree configuration for sdhci2 used with our Kyocera ITS SDIO module.

    ```dts
    mymmc2_pins_default: mymmc2-default-pins {
    pinctrl-single,pins = <
    AM62PX_IOPAD(0x0120, PIN_INPUT_PULLUP, 0) /* MMC2_CMD */
    AM62PX_IOPAD(0x0118, PIN_OUTPUT, 0) /* MMC2_CLK */
    AM62PX_IOPAD(0x011C, PIN_INPUT, 0) /* MMC2_CLKLB */
    AM62PX_IOPAD(0x0114, PIN_INPUT_PULLUP, 0) /* MMC2_DAT0 */
    AM62PX_IOPAD(0x0110, PIN_INPUT_PULLUP, 0) /* MMC2_DAT1 */
    AM62PX_IOPAD(0x010c, PIN_INPUT_PULLUP, 0) /* MMC2_DAT2 */
    AM62PX_IOPAD(0x0108, PIN_INPUT_PULLUP, 0) /* MMC2_DAT3 */
    >;
    };

    &sdhci2 {
    status = "okay";
    vmmc-supply = <&vdd_mmc1>;
    vqmmc-supply = <&vdd_mmc1>;
    pinctrl-names = "default";
    pinctrl-0 = <&mymmc2_pins_default>;
    bus-width = <4>;
    cap-sdio-irq;
    keep-power-in-suspend;
    disable-wp;
    wakeup-source;
    bootph-all;
    };

    Currently:

    cap-sdio-irq is enabled
    keep-power-in-suspend is enabled
    wakeup-source is enabled
    non-removable is not enabled

    Best regards ,

    Izawa

  • 0 in reply to user6235376
    Prodigy 60 points

    Because we were unable to respond in time, we have opened a new ticket for this issue.

    Could you please close this ticket?

    New ticket: AM62P: AM62PX SDIO Issue: "sdio_write(475) insufficient free area" After DAT1 IRQ Stall