From: Daniel Mack <daniel@caiaq.de>
To: Dan Williams <dcbw@redhat.com>
Cc: Sascha Hauer <s.hauer@pengutronix.de>,
linux-mmc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
libertas-dev@lists.infradead.org
Subject: Re: 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
WARNING: multiple messages have this Message-ID (diff)
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: 27+ 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 19:20 ` Daniel Mack
2009-10-21 20:15 ` Dan Williams
2009-10-21 20:15 ` Dan Williams
2009-10-21 20:51 ` Daniel Mack
2009-10-21 20:51 ` Daniel Mack
2009-10-22 8:19 ` Sascha Hauer
2009-10-22 8:19 ` Sascha Hauer
2009-10-22 11:05 ` tommy tommy
2009-10-22 16:41 ` Matt Hsu
2009-10-22 16:41 ` Matt Hsu
2009-10-28 16:47 ` Daniel Mack
2009-10-28 16:47 ` Daniel Mack
2009-10-28 17:06 ` Dan Williams
2009-10-28 17:06 ` Dan Williams
2009-10-28 17:19 ` Daniel Mack
2009-10-28 17:19 ` Daniel Mack
2009-10-28 18:46 ` Dan Williams
2009-10-28 18:46 ` Dan Williams
2009-10-29 10:27 ` Daniel Mack [this message]
2009-10-29 10:27 ` Daniel Mack
2009-11-02 20:00 ` Dan Williams
2009-11-02 20:00 ` Dan Williams
2009-10-28 17:11 ` Dan Williams
2009-10-28 17:11 ` Dan Williams
2009-10-28 17:21 ` Daniel Mack
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=dcbw@redhat.com \
--cc=libertas-dev@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mmc@vger.kernel.org \
--cc=s.hauer@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.