PATCH: Config option to pad SDIO sizes

Pierre Ossman drzeus-mmc at drzeus.cx
Fri Jun 27 13:39:06 EDT 2008


On Fri, 27 Jun 2008 11:37:53 -0400
Dan Williams <dcbw at redhat.com> wrote:

> 
> Pending a look from Pierre, but I think this would probably _also_ be
> better as a module parameter rather than a CONFIG option.  Since the
> addition is done anyway, there shouldn't be a real speed hit.  The
> problem is that in the general world, we have no idea what hardware
> you'll be running this on, and it's better to have one kernel that can
> run on lots of hardware rather than having to flip config options and
> recompile.  I don't think a module parameter would be an issue in
> embedded-land either, right?
> 
> Pierre, is there a better way to fix the crappy SDIO host controller
> thing, or is padding in libertas_sdio what we're stuck with?
> 

I've been toying with the idea of a sdio_readsb_may_pad(). The problem
is how to handle memory allocations in a sane manner. Most controllers
can't do scatter-gather, and it would be wasteful to have bounce so
many requests. Ideas are welcome.

I'm not completely against making the libertas driver more friendly to
broken-beyond-repair controllers. But it's a slippery slope as there
are so many other restrictions that people will start requesting that
we respect. I'd like it all in one place at least.

Perhaps we could do something where there is more chatter back and
forth between card driver and the host driver. The CD could send the HD
a query for how much padding is needed before it does any allocations.
It doesn't handle the alignment issues, but it would be a start.

Rgds
-- 
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  rdesktop, core developer          http://www.rdesktop.org

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.



More information about the libertas-dev mailing list