Hi,
On Fri, Nov 30, 2012 at 07:57:35PM +0100, Daniel Mack wrote:
>
> On 30.11.2012 18:40, Tony Lindgren wrote:
> > * Andreas Fenkart <andreas.fenkart@xxxxxxxxxxxxxxxxxxx> [121130 03:21]:
> >>
> >> The alternative was to configure dat1 line as a GPIO, while
> >> waiting for an IRQ. Then configuring it back as dat1 when the
> >> SDIO card is signalling an IRQ. Or the host starts a transfer. I
> >> guess this will perform poorly, hence not considering it really.
> >
> > This might work for SDIO cards. It should be disabled for data
> > cards naturally to avoid potential data corruption.
I don't understand your concern here, could you explain
> > The way to implement this is set named states in the .dts file
> > for the pins using pinctrl-single.c, then have the MMC driver
> > request states "default" "active" and "idle" during the probe,
> > then toggle between active and idle during the runtime.
> >
> > As far as I remember the GPIO functionality does not need to
> > be enabled, just muxing the pin to GPIO mode for the wake-up
> > is enough.
>
> Wouldn't that be racy, given that an interrupt which occurs at beween
> the point in time when the driver decides to wait for IRQs again until
> the mux has finished switching over, could potentially be lost?
The IRQ is level triggered, so can't be lost. I implemented it as
suggested and surprisingly performance is pretty good. Actually not
worse than keeping the fclk enabled all times.
module: 88W8787 / mwifiex
tx bitrate: 150.0 MBit/s MCS 7 40Mhz short GI
| tcp tx | signal | cpu idle
---------------------------------------------------------------
keep fclk enabled | 50.3 Mbits/sec | -23 dBm | 15 %
suspend/resume | 49.7 Mbits/sec | -22 dBM | 13 %
patch follows
/Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
