[RESEND PATCH v2 1/3] mmc: omap_hsmmc: Enable SDIO IRQ using a GPIO in idle mode.

Tony Lindgren tony at atomide.com
Fri May 24 05:23:16 EST 2013


* Tony Lindgren <tony at atomide.com> [130520 19:55]:
> * Tony Lindgren <tony at atomide.com> [130520 14:03]:
> > * Andreas Fenkart <andreas.fenkart at streamunlimited.com> [130515 01:51]:
> > > Without functional clock the omap_hsmmc module can't forward SDIO IRQs to
> > > the system. This patch reconfigures dat1 line as a gpio while the fclk is
> > > off. When the fclk is present it uses the standard SDIO IRQ detection of
> > > the module.
> > > 
> > > The gpio irq is managed via the 'disable_depth' ref counter of the irq
> > > subsystem, this driver simply calls enable_irq/disable_irq when needed.
> > > 
> > >                       sdio irq    sdio irq
> > >                       unmasked     masked
> > >    -----------------------------------------
> > >     runtime default  |    1     |   2
> > >     runtime suspend  |    0     |   1
> > > 
> > >                   irq disable depth
> > > 
> > > 
> > > only when sdio irq is enabled AND the module is idle, the reference
> > > count drops to zero and the gpio irq is effectively armed.
> > > 
> > > Patch was tested on AM335x/Stream800. Test setup was two modules
> > > with sdio wifi cards. Modules where connected to a dual-band AP, each
> > > module using a different band. One of module was running iperf as server
> > > the other as client connecting to the server in a while true loop. Test
> > > was running for 4+ weeks. There were about 60 Mio. suspend/resume
> > > transitions. Test was shut down regularly.
> > 
> > Looks like this somehow breaks detecting of eMMC on mmc2 for me at least
> > with the non-dt legacyboot. For a removable mmc1 still keeps working.
> > 
> > For mmc2 I have .nonremovable = true and no gpio_cd or gpio_wp.
> 
> Looks like that's because gpio0 is considered valid. But for these pins
> gpio0 is not valid, so let's cut the dependency to updating the pdata
> and ignore gpio0.
> 
> We should also have three pinmux states: default, active and idle to
> avoid remuxing all the pins unnecessarily. The default pins should
> contain the fixed pins, active mmc_dat1, and idle the gpio pin.
> 
> I've attempted to fix up these issues, did not add the wake-up events
> from Steve Sakoman's patch for the non-muxed case:
> 
> http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux.git;a=commitdiff_plain;h=010810d22f6f49ac03da4ba384969432e0320453
> 
> Based on the patch above, sounds like the wake-up events won't work
> for deeper idle states though. But we should probably still support
> those as most people run without the deeper idle states anyways.

Actually, let's go with your patch with the pinmuxing changed. Then
the active state support can be added later on. And let's not add
any pinmuxing callbacks to the legacy booting mode, now there's at
least some reason for people to move on to device tree based booting.
 
> Can you check if the following changes on top of your patch still
> work for you? Note that you need to update your .dts file for the
> new pinctrl states.

Here's your original patch updated for the muxing for the default,
active and idle states.

Regards,

Tony


-------------- next part --------------
A non-text attachment was scrubbed...
Name: andreas-mux-fixed.patch
Type: text/x-diff
Size: 17074 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/devicetree-discuss/attachments/20130523/b6fed0f0/attachment.patch>


More information about the devicetree-discuss mailing list