linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: daniel@caiaq.de (Daniel Mack)
To: linux-arm-kernel@lists.infradead.org
Subject: MXC MMC driver and SDIO peripherals
Date: Wed, 28 Oct 2009 17:47:52 +0100	[thread overview]
Message-ID: <20091028164752.GN29442@buzzloop.caiaq.de> (raw)
In-Reply-To: <1256156119.8469.40.camel@localhost.localdomain>

On Wed, Oct 21, 2009 at 01:15:19PM -0700, Dan Williams wrote:
> On Wed, 2009-10-21 at 21:20 +0200, Daniel Mack wrote:
> > Hi,
> > 
> > we're having trouble getting SDIO connected harware to fly on MX31 based
> > designs. In particular, a SD8686 chip supported by the libertas_sdio
> > driver will hang forever when built without CONFIG_MMC_DEBUG=y. With
> > that option selected, however, the behaviour is a little different, and
> > I can at least see the following messages on a recent 2.6.32-rc5 based
> > MX31 tree.
> > 
> > Is there any common pitfall for such setups? I did more or less the same
> > thing on PXAs (same WLAN chip, same kind of interface, same firmware),
> > and haven't seen any such effects, so I suspect the MXC specific parts
> > to be the reason for that. Any ideas?
> 
> Any idea what quirks your SDHC is using if any?  Does it require PIO or
> can it do DMA?  Does it have any transfer restrictions on block size or
> bit-width?  What is the debug output of the MMC stack when loading the
> module for your SDHC?

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

Any idea how to get that working with only single block small transfers?

Btw - there's a number of things missing for SDIO in the MXC MMC driver
which I implemented/fixed. I'll send patches as soon as I have more
confidence about the whole setup.


Thanks,
Daniel


[1] Errata IDs TLSbo91748 and TLSbo78667 from
    http://www.freescale.com/files/32bit/doc/errata/MCIMX31CE.pdf?fpsp=1

  parent reply	other threads:[~2009-10-28 16:47 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 [this message]
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
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=20091028164752.GN29442@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).