From: Michael Hunold <hidden> Date: 2012-03-12 08:45:07
Hi,
I am using a Freescale iMX53 Quick Start Board. The uSD card that comes
with the device contains a Linux kernel labeled "Linux version
2.6.35.3-01129-g691c08a-dirty".
After some digging I found out that this corresponds to the
"imx_2.6.35_11.09.01" tag in the Freescale Linux kernel that can be
found at http://opensource.freescale.com/pub/scm/imx/linux-2.6-imx.git
I am experimenting with an SDIO card and that one works fine using that
kernel. So far, so good.
Now I have tried to use a vanilla Git Linux kernel (3.3.0-rc6+) with
mixed results.
The card is recognised correctly and mostly initialised, up to the point
where an apparently an interrupt from the card is expected to happen.
Because the SDHCI driver supports "real" interrupts (via
MMC_CAP_SDIO_IRQ) the SDIO IRQ thread goes to sleep, but is never woken
up in my case.
After about 2.5 seconds, I receive an error -110 (timeout) and the
initialisation is aborted.
So my question is: is anybody using an iMX53 (or any other hardware
using the SDHCI driver) together with "real" interrupts (via
MMC_CAP_SDIO_IRQ), not polled interrupts?
The main problem is that the ancient Freescale 2.6.35 kernel is using
the "mx_sdhci" driver, while in 3.3.0-rc6+ the generic "sdhci" driver is
used, so it's not possible to simply compare the changes between the two
versions. :-(
Does anybody know the difference between the "mx_sdhci" from Freescale
2.6.35 kernel and the the "sdhci" driver in 3.3.0-rc6+?
Probably this is a question for the Freescale people: why was the
"mx_sdhci" necessary at all and why is it not necessary any more?
Any help, hints and historical informations are highly appreciated,
before I start to look deeper into this problem.
CU
Michael.
From: Wolfram Sang <hidden> Date: 2012-03-12 10:10:37
Hi,
The main problem is that the ancient Freescale 2.6.35 kernel is using
the "mx_sdhci" driver, while in 3.3.0-rc6+ the generic "sdhci" driver is
used, so it's not possible to simply compare the changes between the two
versions. :-(
Not via diff, but the structure of both drivers should still be somewhat
similar.
Probably this is a question for the Freescale people: why was the
"mx_sdhci" necessary at all
It probably was never necessary, it was just easier to hack on a forked
driver, because you can't break other sdhci-users, I guess. Since large
portions of the code are duplicated but issues have been fixed in a
very, ahem, custom manner, this was never suitable for mainline. Back
then, most vendors thought this is good enough. Luckily, times have
changed a bit.
and why is it not necessary any more?
Because I wanted SD support in mainline, so I had to take a different
path.
Any help, hints and historical informations are highly appreciated,
before I start to look deeper into this problem.
From: Michael Hunold <hidden> Date: 2012-03-12 10:40:15
Hello Wolfram,
thank you for your answer.
on 12.03.2012 11:10 Wolfram Sang said the following:
quoted
Probably this is a question for the Freescale people: why was the
"mx_sdhci" necessary at all
It probably was never necessary, it was just easier to hack on a forked
driver, because you can't break other sdhci-users, I guess. Since large
portions of the code are duplicated but issues have been fixed in a
very, ahem, custom manner, this was never suitable for mainline. Back
then, most vendors thought this is good enough. Luckily, times have
changed a bit.
Yes, I know that thinking.
quoted
and why is it not necessary any more?
Because I wanted SD support in mainline, so I had to take a different
path.
I understand.
quoted
Any help, hints and historical informations are highly appreciated,
before I start to look deeper into this problem.
They don't have a common ancestor. Just dig into both, you will
recognize patterns, I guess.
Ok, to sum this up:
SDIO IRQs are working in mx_sdhci in the Freescale tree because it was
properly implemented and tested, obviously.
SDIO IRQs are working for sdhci in mainline probably for other
non-freescale platforms.
You fixed the generic sdhci driver in mainline to work with iMX53 to get
rid of the need for mx_sdhci, but probably never got the chance to test
if SDIO IRQs are really working.
That means, the subtle difference between mx_sdhci and sdhci to get SDIO
IRQS to work on sdhci with iMX53 has yet to be found.
From: Wolfram Sang <hidden> Date: 2012-03-12 11:06:24
Ok, to sum this up:
SDIO IRQs are working in mx_sdhci in the Freescale tree because it was
properly implemented and tested, obviously.
Not sure about "properly", but, yes ;)
SDIO IRQs are working for sdhci in mainline probably for other
non-freescale platforms.
Probably, but I can't say 'yes' for sure. You'd need to find out.
You fixed the generic sdhci driver in mainline to work with iMX53 to get
rid of the need for mx_sdhci, but probably never got the chance to test
if SDIO IRQs are really working.
I worked mainly with MX25/35 back then, and a little bit with MX51. IIRC
I only had an SDIO card for which no Linux drivers were available, so I
only could test that the card was detected :(
That means, the subtle difference between mx_sdhci and sdhci to get SDIO
IRQS to work on sdhci with iMX53 has yet to be found.