From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tony Lindgren Subject: Re: omap_hsmmc: SDIO IRQ on AM335x family Date: Thu, 3 Jan 2013 11:48:51 -0800 Message-ID: <20130103194851.GH25633@atomide.com> References: <20121130111847.GA24674@blumentopf> <20121130174022.GM5312@atomide.com> <50B9019F.2020109@gmail.com> <20121220220444.GA350@blumentopf> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mho-03-ewr.mailhop.org ([204.13.248.66]:20201 "EHLO mho-01-ewr.mailhop.org" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753710Ab3ACTs5 (ORCPT ); Thu, 3 Jan 2013 14:48:57 -0500 Content-Disposition: inline In-Reply-To: <20121220220444.GA350@blumentopf> Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Andreas Fenkart Cc: Daniel Mack , Chris Ball , devicetree-discuss@lists.ozlabs.org, linux-mmc@vger.kernel.org, linux-omap@vger.kernel.org, santosh.shilimkar@ti.com * Andreas Fenkart [121220 14:07]: > 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 [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 Hey that's cool :) Will take a look at the patch. Tony