iMX31 and 88W8686 SDIO module

[Holger Schurig]

> As I know the linux driver of Marvell 88w8686 have two
> branch. One is libertas and other one is release by
> Marvell.

Not sure if "branch" is the right word.

The libertas driver in Linux is now VERY different from the
Marvell driver. When you get a linux kernel via git and do an

  git log --pretty=oneline drivers/net/wireless/libertas | wc --lines

on it, you'll see that we made around 413 patches on top of it.
(413 is the number from the current wireless-testing tree).
Many patches have been cosmetic or stylistic, to bring the
driver in line to the common linux-way-of-doing things. But we
also fixed a couple of bug reports, e.g. when it comes to
spinlock issues, uninitialized variables, scheduler issues.

So the benefit of the linux libertas driver is: better quality,
more and public code review.

The benefit of the Marvell driver is internal knowledge. However,
their drawback is that they hide information from the greater
linux community and don't play well. I'd actually go so far and
say that for new product designs I'd choose other companies that
aren't hiding things. The thing is: the more talentend engeneers
have access to things, the better the result. And if a website
(like Marvell's) hide behind things like "Only corporate emails
will be accepted" -- on their register for login web page) they
don't understand a bit.




> First I try libertas on our platform. But I 
> stuck at firmware loading and I don't have any idea
> about that. And I try the driver from moblin project
> based on Marvell GPL driver. After several day working,
> the driver work right now.

Can you publish your changes to this list for the benefit of
other SDIO people?  If they see how you changed the Marvell v9
driver, maybe someone else (or even you) can mimick the same for
the Linux-libertas driver. And as the Linux-libertas driver has a
much better code quality, it would be nice for everybody.


> But the driver still have some problem. The current can scan
> and associate to ap but performance is very awful (TCP
> 700kbps , UDP 1Mbps).

Kilobit per second?  Oh, 70 kByte/s is slow. Did you turn debug
off?

> And associate and  query operation will make 
> kernel bug (BUG()) like below message.

> BUG: scheduling while atomic: iwconfig/0x00000001/1640

Hehe, that is one of the bugs that the Linux-libertas driver
fixed.



> I still want to know why libertas don't work and
> marvell driver work. Could anyone give me some hint
> about that ?

Have a look at my mail "change report from old OLPC-code to
moblinux-v9". In this mail I compared the ancestor of the
Linux-libertas driver to the moblinux v9 driver. Search in this
mail for the string "SDIO". I found two or three places where
they put SDIO specific code into the middle of the main driver.

You might also want to compare VERY low-level what get's sent to
the SDIO stack. For example, in the if_cs.c file, I have this:

#ifdef DEBUG_IO
static int debug_output = 0;
#else
/* This way the compiler optimizes the printk's away */
#define debug_output 0
#endif

static inline unsigned int if_cs_read8(struct if_cs_card *card, uint reg)
{
        unsigned int val = ioread8(card->iobase + reg);
        if (debug_output)
                printk(KERN_INFO "inb %08x<%02x\n", reg, val);
        return val;
}
// the same code in if_cs_read16(), if_cs_write8(), if_cs_write16().

The compiler is intellegent enought to optimize the if() out if
debug_output is defined as 0 and inline the function, so that
in the normal case (DEBUG_IO not defined) it won't harm at all.
But with #define DEBUG_IO, I trace EVERY hardware access.

Turning this one obviously produces a huge log and make things
even slower, but this code helped me when programmed the firmware
download code.

Put something like this into the Marvell driver, let it run
the firmware and save the dmesg/syslog file. The put something like
this into the if_sdio.c file of the Linux libertas driver, let
it download the firmware and compare. You'll probably see some
differences and here, voila, is the place to attack.