Prev: [PATCH] x86, AMD: Extend support to future families
Next: [RFC][PATCH 04/26] MIPS: JZ4740: Add timer support
From: Maxim Levitsky on 2 Jun 2010 15:00
Hi,

Maybe this is my fault, don't know, but I found and now confident that
new and possible old version of ricoh-mmc causes troubles after
suspend/resume.

Namely there are two problems.
One is that sometimes card detection on xD controller stops working.
That is it doesn't respond to insert/remove events, and suspend to ram
just updates that once. Granted I wrote this driver, but it appears to
work without richoh-mmc.

Another problem that is unrelated to xD is that sometimes sdhci
conroller issues an interrupt storm, and does so until its driver is
reloaded. At that point it refuses to load with missing voltage levels.

I never seen these without ricoh-mmc pci quirk.

Both problems are semi-rare.

So just one question, did you see these problems?
Do you have a clue on how to proceed?


Best regards,
Maxim Levitsky

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Philip Langdale on 2 Jun 2010 16:00

On Wed, 02 Jun 2010 21:56:58 +0300, Maxim Levitsky
<maximlevitsky(a)gmail.com> wrote:
> Hi,
>
> Maybe this is my fault, don't know, but I found and now confident that
> new and possible old version of ricoh-mmc causes troubles after
> suspend/resume.
>
> Namely there are two problems.
> One is that sometimes card detection on xD controller stops working.
> That is it doesn't respond to insert/remove events, and suspend to ram
> just updates that once. Granted I wrote this driver, but it appears to
> work without richoh-mmc.
>
> Another problem that is unrelated to xD is that sometimes sdhci
> conroller issues an interrupt storm, and does so until its driver is
> reloaded. At that point it refuses to load with missing voltage levels.
>
> I never seen these without ricoh-mmc pci quirk.
>
> Both problems are semi-rare.
>
> So just one question, did you see these problems?
> Do you have a clue on how to proceed?

I have never seen these problems, but I could imagine that perhaps the
PCI register pokes have side-effects or there's actually more that needs
to be done than what we currently have. No one has access to the relevant
datasheets so the magic incantations are second hand. More worryingly, it
may not be a well supported configuration - while the other controllers
might be disabled based on physical slot design, SD and MMC are the same,
so I doubt Ricoh or OEMs have ever seriously considered having only one
on. I've not heard of the sdhci problem before - maybe your hardware is
dodgy? :-)

--phil
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Maxim Levitsky on 2 Jun 2010 16:20
On Wed, 2010-06-02 at 15:54 -0400, Philip Langdale wrote:
> On Wed, 02 Jun 2010 21:56:58 +0300, Maxim Levitsky
> <maximlevitsky(a)gmail.com> wrote:
> > Hi,
> >
> > Maybe this is my fault, don't know, but I found and now confident that
> > new and possible old version of ricoh-mmc causes troubles after
> > suspend/resume.
> >
> > Namely there are two problems.
> > One is that sometimes card detection on xD controller stops working.
> > That is it doesn't respond to insert/remove events, and suspend to ram
> > just updates that once. Granted I wrote this driver, but it appears to
> > work without richoh-mmc.
> >
> > Another problem that is unrelated to xD is that sometimes sdhci
> > conroller issues an interrupt storm, and does so until its driver is
> > reloaded. At that point it refuses to load with missing voltage levels.
> >
> > I never seen these without ricoh-mmc pci quirk.
> >
> > Both problems are semi-rare.
> >
> > So just one question, did you see these problems?
> > Do you have a clue on how to proceed?
>
> I have never seen these problems, but I could imagine that perhaps the
> PCI register pokes have side-effects or there's actually more that needs
> to be done than what we currently have. No one has access to the relevant
> datasheets so the magic incantations are second hand. More worryingly, it
> may not be a well supported configuration - while the other controllers
> might be disabled based on physical slot design, SD and MMC are the same,
> so I doubt Ricoh or OEMs have ever seriously considered having only one
> on. I've not heard of the sdhci problem before - maybe your hardware is
> dodgy? :-)


Thanks.
I some future I maybe consider reverse engineering the MMC controller.

Best regards,
Maxim Levitsky

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Philip Langdale on 2 Jun 2010 16:50

On Wed, 02 Jun 2010 23:19:25 +0300, Maxim Levitsky
<maximlevitsky(a)gmail.com> wrote:
>
> Thanks.
> I some future I maybe consider reverse engineering the MMC controller.

Someone actually did, if you dig back through the SDHCI mailing list. It's
apparently almost identical to SDHCI with the Cap flags not set properly.

http://list.drzeus.cx/pipermail/sdhci-devel/2007-December/002085.html

Still, even if we got it working properly, it would be rather less elegant
than what we have today, modulo hardware freaking out as you are
experiencing...

--phil
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Maxim Levitsky on 2 Jun 2010 18:10
On Wed, 2010-06-02 at 16:42 -0400, Philip Langdale wrote:
> On Wed, 02 Jun 2010 23:19:25 +0300, Maxim Levitsky
> <maximlevitsky(a)gmail.com> wrote:
> >
> > Thanks.
> > I some future I maybe consider reverse engineering the MMC controller.
>
> Someone actually did, if you dig back through the SDHCI mailing list. It's
> apparently almost identical to SDHCI with the Cap flags not set properly.
This is just great.

Maybe its even possible to make SDHCI use it.

>
> http://list.drzeus.cx/pipermail/sdhci-devel/2007-December/002085.html
>
> Still, even if we got it working properly, it would be rather less elegant
> than what we have today, modulo hardware freaking out as you are
> experiencing...
The curreent version is very elegant....
Like once you resume the system, insert card and is out of ideas of what
to do next....

Thank you very much!


Best regards,
Maxim Levitsky

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 |  Next  |  Last
Pages: 1 2
Prev: [PATCH] x86, AMD: Extend support to future families
Next: [RFC][PATCH 04/26] MIPS: JZ4740: Add timer support