Re: SDHCI: mdelay() in hot path in esdhc_pltfm_set_clock looses CAN (!) frames

[Russell King - ARM Linux]

On Tue, Jul 07, 2015 at 03:17:08PM -0300, Fabio Estevam wrote:
> On Tue, Jun 30, 2015 at 10:43 AM, Holger Schurig
> <holgerschurig@xxxxxxxxx> wrote:
> > So it seems that esdhc_pltfm_set_clock() somehow waits. And really
> > there is an mdelay(1) there. So it waits a whopping millisecond there!
> >
> > What's worse: I put a printk() into this function, just before the
> > mdelay(). And it get's called hundreds of times when I boot, or when I
> > update via rsync. And I believe that for each call the mdelay() kills
> > preemption.

The whole SDHCI thing remains a total trainwreck.  Sorry guys, that's
precisely what it is.  That damned driver needs rewriting to be a
library, the quirks need to be killed, and handled in specific driver
code for the variants with a library of core functions.

Then, the whole set_ios() thing in MMC needs killing and replaced with
a functional interface instead - "turn power on" "initialise/turn clock
on" "set clock speed" etc.

I suspect if that were to happen, then we'd get rid of a lot of those
mdelay()s you're seeing, because the problem sdhci has today is that
it's virtually impossible to work out what each set_ios() call into
the code is trying to achieve (well, we can work that out, what can't
be worked out is whether splitting the code is going to break some
random sdhci host, so the risk of causing breakage is high - hence
sdhci in its current form is basically unmaintainable.)

I've been saying this for quite some time - I put some work into it a
couple of years ago to try and clean up some of the crap there, but
since then people have continued with their same old ideas, adding
yet more quirk bits to those damned quirk variables, adding intercepts
for register accesses which all makes the issue worse, rather than
addressing the fundamental problem.

It needs a huge amount of effort put into it...

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/