Thread (27 messages) 27 messages, 6 authors, 2021-04-09

Re: [PATCH 4/4] ARM: dts: Fix-up EMMC2 controller's frequency

From: Nicolas Saenz Julienne <hidden>
Date: 2021-04-05 08:45:35
Also in: linux-devicetree, linux-mmc, lkml

Hi Alan,

On Thu, 2021-04-01 at 11:23 -0400, Alan Cooper wrote:
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?
In my experience, it's only eMMC that needs the clock to be retried
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.
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.
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.
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.
Al
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help