From: daniel@caiaq.de (Daniel Mack)
To: linux-arm-kernel@lists.infradead.org
Subject: MXC MMC driver and SDIO peripherals
Date: Thu, 29 Oct 2009 11:27:51 +0100 [thread overview]
Message-ID: <20091029102751.GO14091@buzzloop.caiaq.de> (raw)
In-Reply-To: <1256749562.3850.41.camel@localhost.localdomain>
On Wed, Oct 28, 2009 at 10:06:02AM -0700, Dan Williams wrote:
> On Wed, 2009-10-28 at 17:47 +0100, Daniel Mack wrote:
> > I did some more research on this and it turns out that the problem is
> > related to multi block transfers. At least, this is when it first
> > occurs.
> >
> > The libertas SDIO driver downloads two firmwares to the device, one
> > 'helper' and one 'real' firmware The first one only uses chunks of 64
> > bytes each and that seems to work fine. The real firmware, however,
> > loads in 512 bytes chunks which the SDIO core breaks up into 16 blocks
> > of 32 bytes. And this is where the MXC host controller bails out with a
> > CRC error. Unfortunately, it does not give any more detailed information
> > about what exactly went wrong.
> >
> > The effect might be related to an errata entry[1], which is what I'm
> > currently investigating. To do so, I would like to limit the the
> > communication to singe-block transfers, just to exclude all other
> > possible (electrical, clock speed, ...) issues. I did that by setting
> > mmc->max_blk_count to 1 in the the host controller, but then again,
> > the libertas driver and/or the firmware doesn't like that and dies in
> > if_sdio_pro_real() with
> >
> > firmware wants 17 bytes
> > firmware helper signalled error
A number of bytes requested has bit 1 set indicates an error, according
to the code if_sdio_prog_real(). Is there any more information in such
cases? An error code that tells us about the real reason maybe?
> All the Marvell documentation (v5 at least) refers to 512-byte transfers
> of the second-stage firmware in 32-byte blocks:
>
> Section 2.2.1.1 of the v5 spec states:
What documentation is that? Is it publically available?
Thanks,
Daniel
next prev parent reply other threads:[~2009-10-29 10:27 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-21 19:20 MXC MMC driver and SDIO peripherals Daniel Mack
2009-10-21 20:15 ` Dan Williams
2009-10-21 20:51 ` Daniel Mack
2009-10-22 8:19 ` Sascha Hauer
2009-10-22 11:05 ` tommy tommy
2009-10-22 16:41 ` Matt Hsu
2009-10-28 16:47 ` Daniel Mack
2009-10-28 17:06 ` Dan Williams
2009-10-28 17:19 ` Daniel Mack
2009-10-28 18:46 ` Dan Williams
2009-10-29 10:27 ` Daniel Mack [this message]
2009-11-02 20:00 ` Dan Williams
2009-10-28 17:11 ` Dan Williams
2009-10-28 17:21 ` Daniel Mack
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=20091029102751.GO14091@buzzloop.caiaq.de \
--to=daniel@caiaq.de \
--cc=linux-arm-kernel@lists.infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).