Nicolas,

I got a better description of the failure and it looks like the bus
clock needs to be limited to 300KHz for a 500MHz core clock.
What's happening is that an internal reset sequence is needed after a
command timeout and the reset signal needs to be asserted for at least
2 ticks of the bus clock. This is done using a 12 bit counter clocked
by the core clock. That means a 500MHz core clock produces a 122KHz
reset signal which is too fast for 2 ticks of the 200KHz bus clock
(100KHz) but is okay for the 300KHz (150Khz) bus clock.

Al

On Mon, Apr 5, 2021 at 4:45 AM Nicolas Saenz Julienne
[off-list ref] wrote:

Hi Alan,

On Thu, 2021-04-01 at 11:23 -0400, Alan Cooper wrote:

quoted

Nicolas,

Sorry, I just noticed this thread.
This is a known bug in some newer Arasan cores.
The problem happens when the difference between the core clock and the bus
clock is too great.
Limiting the clock to 200KHz minimum should be a good fix.

Great, that's what I was hoping to hear :). Out of curiosity, can you share
more details on how the failure occurs?

quoted

In my experience, it's only eMMC that needs the clock to be retried

quoted

below 400KHz and not SD or SDIO. That's because the CMD signal for
eMMC starts out as open-drain during identification and the size of
the pull-up on the CMD signal can require the <400KHz clock. Once eMMC
is out of identification mode the CMD signal is switched to push-pull
and can run at much higher clock rates.

Fair enough, I need to do some tests, some of the compute modules use an eMMC.

quoted

I don't think that SD and SDIO have any open-drain signals, so they
shouldn't need to retry at slower clock speeds.

Noted.

quoted

I'm trying to get more detail on the bug, like the exact ratio of core
clock to bus clock that causes the problem. When I first found this
bug I was told that the failure would not happen at 200KHz, but we
were using a 405MHz core clock.

That would be nice to have.

quoted

One other question. Why are you using polling for the SD card, this
newer controller supports the interrupt driven "Card Inserted" signal
and avoids wasting time polling?

I believe the line isn't routed on RPi4.

quoted

Al

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel