From: Michael Hunold <hunold@linuxtv.org>
To: Wolfram Sang <w.sang@pengutronix.de>
Cc: linux-mmc@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: iMX53 and MMC_CAP_SDIO_IRQ
Date: Mon, 12 Mar 2012 11:40:15 +0100 [thread overview]
Message-ID: <4F5DD28F.50600@linuxtv.org> (raw)
In-Reply-To: <20120312101037.GA2459@pengutronix.de>
Hello Wolfram,
thank you for your answer.
on 12.03.2012 11:10 Wolfram Sang said the following:
>> 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.
>> 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.
>> 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.
> Regards,
> Wolfram
CU
Michael.
WARNING: multiple messages have this Message-ID (diff)
From: hunold@linuxtv.org (Michael Hunold)
To: linux-arm-kernel@lists.infradead.org
Subject: iMX53 and MMC_CAP_SDIO_IRQ
Date: Mon, 12 Mar 2012 11:40:15 +0100 [thread overview]
Message-ID: <4F5DD28F.50600@linuxtv.org> (raw)
In-Reply-To: <20120312101037.GA2459@pengutronix.de>
Hello Wolfram,
thank you for your answer.
on 12.03.2012 11:10 Wolfram Sang said the following:
>> 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.
>> 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.
>> 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.
> Regards,
> Wolfram
CU
Michael.
next prev parent reply other threads:[~2012-03-12 10:40 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-12 8:45 iMX53 and MMC_CAP_SDIO_IRQ Michael Hunold
2012-03-12 8:45 ` Michael Hunold
2012-03-12 10:10 ` Wolfram Sang
2012-03-12 10:10 ` Wolfram Sang
2012-03-12 10:40 ` Michael Hunold [this message]
2012-03-12 10:40 ` Michael Hunold
2012-03-12 11:06 ` Wolfram Sang
2012-03-12 11:06 ` Wolfram Sang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F5DD28F.50600@linuxtv.org \
--to=hunold@linuxtv.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mmc@vger.kernel.org \
--cc=w.sang@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.