AM3357: MMC controller soft reset behavior

Hi,

The MMC experts have been notified. They will respond here.

Some additional information from customer.

- Current code handling SD_SYSCTL.SRC or SRD is not suitable for the case when t0+t1 is shorter than 1usec.
- There are possibilities the code is preempted between (a) and (b) in PREEMPT_RT case. This needs to be addressed somehow.

Thanks and regards,
KoT

KoT,

A couple of clarifying questions:
1. What specific version of the Processor SDK is this? Or, specific Linux kernel?
2. Can you provide a high-level description of the problem? When do they see the timeout? How often? Across multiple boards?
3. Have they made any changes to the code that would be applicable?

Hi Ron,

1. Customer uses Processor SDK RT v3.02(Kernel v4.4.19).
2. The omap_hsmmc_reset_controller_fsm() is called when no response to CMD comes back from a card. In such scenario, the code cannot detect SRC bit=1 and 20msec timeout happens. I need to check issue occurrence and board dependency.
3. I think no.

I am afraid current code is not correct. The SRC bit timing is not necessarily captured by 1usec interval.

Thanks and regards,
KoT

Hi Ron,

I got additional information from customer.

There is no board / card dependency.
The occurrence of the issue depends on whether the code is preempted while SYSCTL src/srd bit is polling or not.
So the issue should not be found with normal kernel (i.e. non-RT Linux).
As customer uses RT Linux, there are chances the code is preempted while src/srd bit is polling with udelay(1).
And if 0=>1=>0 bit transition cannot be detected, the polling loop continues until timeout and it occupies CPU resource for 20msec.

This is a problem to meet customer’s real time requirement.

If we can provide the time needed the 0=>1=>0 transition (and it is small enough), customer will keep the period non-preempt(or interrupt disabled).
Do we have the value ?

Thanks and regards,
KoT

Can you tell me exactly how you are testing this? I would like to recreate it the same way. Are there any analyzer captures that can be posted?

Steve K.

Also, are you seeing the timeout error message "Timeout waiting on controller reset in.."

Steve K.

Hi Steve,

Here are steps customer reproduce the issue on board.

1) Use Linux with preempt_rt patch
2) No SD card is inserted
3) At the user console, repeat insmod / rmmod omap_hsmmc.ko at user console
4) Because no card is inserted, omap_hsmmc_reset_controller_fsm() is called

5) If omap_hsmmc_reset_controller_fsm() is preempted just after SRC/SRD is written to ‘1’, the code missed to catch SRC/SRD=1 state, then timeout happens.

Customer does not see below message.
>Also, are you seeing the timeout error message "Timeout waiting on controller reset in.."

Thanks and regards,
KoT

Hi Steve,

Here are additional information from customer.

>Also, are you seeing the timeout error message "Timeout waiting on controller reset in.."

The reason why customer does not see the message is the omap_hsmmc_reset_controller_fsm() implementation.
Please see attached pptx (I added page#2 ).
hsmmc_reset_Feb282017.pptx
Because the error message checks only the bit is stuck at ‘1’, the message is not shown in case bit change to ‘1’ is never detected.

So the issue is visible only when other threads (lower priority than omap_hsmmc_reset_controller_fsm()) are blocked for 20msec.
(For example, another thread periodically(2msec) sends a packet is blocked for 20msec.)

Or if you insert debug code something like;

if(i > limit) printkf("SYSCTL transition missed.");

Just after

              if (mmc_slot(host).features & HSMMC_HAS_UPDATED_RESET) {
                            while ((!(OMAP_HSMMC_READ(host->base, SYSCTL) & bit))
                                                                      && (i++ < limit))
                                          udelay(1);
              }
             
You can see the issue at the console.

Thanks and regards,

KoT