PATCH: Config option to pad SDIO sizes
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.
-- 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
More information about the libertas-dev