public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: "Madhusudhan" <madhu.cr@ti.com>
To: 'Dirk Behme' <dirk.behme@googlemail.com>
Cc: linux-mmc@vger.kernel.org, 'John Rigby' <jcrigby@gmail.com>,
	linux-omap@vger.kernel.org, 'Steve Sakoman' <sakoman@gmail.com>
Subject: RE: MMC_CAP_SDIO_IRQ for omap 3430
Date: Fri, 16 Oct 2009 16:14:43 -0500	[thread overview]
Message-ID: <004701ca4ea5$aeacefe0$544ff780@am.dhcp.ti.com> (raw)
In-Reply-To: <4AD8C959.1000004@googlemail.com>



> -----Original Message-----
> From: Dirk Behme [mailto:dirk.behme@googlemail.com]
> Sent: Friday, October 16, 2009 2:28 PM
> To: Madhusudhan Chikkature
> Cc: linux-mmc@vger.kernel.org; John Rigby; linux-omap@vger.kernel.org;
> Steve Sakoman
> Subject: Re: MMC_CAP_SDIO_IRQ for omap 3430
> 
> Madhusudhan Chikkature wrote:
> > Hi Dirk,
> >
> > I am inlining the patch so that it helps review.
> ...
> > @@ -1165,8 +1178,15 @@ static void omap_hsmmc_set_ios(struct mm
> >  		break;
> >  	case MMC_BUS_WIDTH_4:
> >  		OMAP_HSMMC_WRITE(host->base, CON, con & ~DW8);
> > -		OMAP_HSMMC_WRITE(host->base, HCTL,
> > -			OMAP_HSMMC_READ(host->base, HCTL) | FOUR_BIT);
> > +		if (mmc_card_sdio(host->mmc->card)) {
> >
> > I wish it could be moved to "enable_sdio_irq" so that we can avoid
> inclusion of
> > card.h and checking the type of card in the host controller driver.
> 
> Yes, this would be the real clean way. But ...
> 
> > But the
> > dependancy on 4-bit seems to be a problem here.
> 
> ... most probably we have to find a workaround until (if ever?) above
> clean implementation is available.
> 
> What we need is after SDIO mode and bus width is known, and before the
> first interrupt comes, to set IBG.
> 
> > On the problems being discussed on testing is the interrupt source
> geting
> > cleared at the SDIO card level upon genaration of the CIRQ? If not it
> remains
> > asserted.
> 
> Yes, this seems to be exactly the problem John reports in his follow
> up mail.
> 
> Any hint how to clear SDIO interrupt?
> 
On the controller side I guess it is cleared when you pass "disable" in the
enable_sdio_irq" fn. This happens when you call mmc_signal_sdio_irq.

I am not too sure about how it gets disabled from the card side. I see that
SDIO core has a function "sdio_release_irq" which is used by the sdio uart
driver. The usage of this could give a clue.

Regards,
Madhu

> Many thanks
> 
> Dirk
> 
> > +			OMAP_HSMMC_WRITE(host->base, HCTL,
> > +					 OMAP_HSMMC_READ(host->base, HCTL)
> > +					 | IBG | FOUR_BIT);
> > +		} else {
> > +			OMAP_HSMMC_WRITE(host->base, HCTL,
> > +					 OMAP_HSMMC_READ(host->base, HCTL)
> > +					 | FOUR_BIT);
> > +		}
> >  		break;
> >  	case MMC_BUS_WIDTH_1:
> >  		OMAP_HSMMC_WRITE(host->base, CON, con & ~DW8);
> > @@ -1512,6 +1532,24 @@ static int omap_hsmmc_disable_fclk(struc
> >  	return 0;
> >  }
> >
> > +static void omap_hsmmc_enable_sdio_irq(struct mmc_host *mmc, int
> enable)
> > +{
> > +	struct omap_hsmmc_host *host = mmc_priv(mmc);
> > +	u32 ie, ise;
> > +
> > +	ise = OMAP_HSMMC_READ(host->base, ISE);
> > +	ie  = OMAP_HSMMC_READ(host->base, IE);
> > +
> > +	if (enable) {
> > +		OMAP_HSMMC_WRITE(host->base, ISE, ise | CIRQ_ENABLE);
> > +		OMAP_HSMMC_WRITE(host->base, IE,  ie  | CIRQ_ENABLE);
> > +	} else {
> > +		OMAP_HSMMC_WRITE(host->base, ISE, ise & ~CIRQ_ENABLE);
> > +		OMAP_HSMMC_WRITE(host->base, IE,  ie  & ~CIRQ_ENABLE);
> > +	}
> > +
> > +}
> > +
> >  static const struct mmc_host_ops omap_hsmmc_ops = {
> >  	.enable = omap_hsmmc_enable_fclk,
> >  	.disable = omap_hsmmc_disable_fclk,
> > @@ -1519,7 +1557,7 @@ static const struct mmc_host_ops omap_hs
> >  	.set_ios = omap_hsmmc_set_ios,
> >  	.get_cd = omap_hsmmc_get_cd,
> >  	.get_ro = omap_hsmmc_get_ro,
> > -	/* NYET -- enable_sdio_irq */
> > +	.enable_sdio_irq = omap_hsmmc_enable_sdio_irq,
> >  };
> >
> >  static const struct mmc_host_ops omap_hsmmc_ps_ops = {
> > @@ -1529,7 +1567,7 @@ static const struct mmc_host_ops omap_hs
> >  	.set_ios = omap_hsmmc_set_ios,
> >  	.get_cd = omap_hsmmc_get_cd,
> >  	.get_ro = omap_hsmmc_get_ro,
> > -	/* NYET -- enable_sdio_irq */
> > +	.enable_sdio_irq = omap_hsmmc_enable_sdio_irq,
> >  };
> >
> >  #ifdef CONFIG_DEBUG_FS
> > @@ -1734,7 +1772,7 @@ static int __init omap_hsmmc_probe(struc
> >  	mmc->max_seg_size = mmc->max_req_size;
> >
> >  	mmc->caps |= MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
> > -		     MMC_CAP_WAIT_WHILE_BUSY;
> > +		     MMC_CAP_WAIT_WHILE_BUSY | MMC_CAP_SDIO_IRQ;
> >
> >  	if (mmc_slot(host).wires >= 8)
> >  		mmc->caps |= MMC_CAP_8_BIT_DATA;
> >
> >
> >
> >
> >
> >> John Rigby wrote:
> >>> I have seen several discussions about lack of sdio irq support in the
> >>> hsmmc driver but no patches.  Has anyone on this list implemented this
> >>> and/or can anyone point me to patches?
> >> What a coincidence ;)
> >>
> >> I'm currently working on this. See attachment what I currently have.
> >> It is compile tested only against recent omap linux head. I don't have
> >> a board using SDIO at the moment, so no real testing possible :(
> >>
> >> Some background, maybe it helps people to step in:
> >>
> >> Gumstix OMAP3 based Overo air board connects Marvell 88W8686 wifi by
> >> MMC port 2 in 4 bit configuration [1]. The wifi performance is quite
> >> bad (~100kB/s). There is some rumor that this might be SDIO irq
> >> related [2]. There was an attempt to fix this [3] already, but this
> >> doesn't work [4]. Having this, I started to look into it.
> >>
> >> I used [3], the TI Davinci driver [5] (supporting SDIO irq), the SDIO
> >> Simplified Specification [6] and the OMAP35x TRM [7] as starting
> points.
> >>
> >> Unfortunately, the Davinci MMC registers and irqs are different
> >> (Davinci has a dedicated SDIO irq). But combining [3] and [5] helps to
> >> get an idea what has to be done.
> >>
> >> I think the main issues of [3] were that it doesn't enable IBG for 4
> >> bit mode ([6] chapter 8.1.2) and that mmc_omap_irq() doesn't reset the
> >> irq bits.
> >>
> >> Topics I still open:
> >>
> >> - Is it always necessary to deal with IE _and_ ISE register? I'm not
> >> totally clear what the difference between these two registers are ;)
> >> And in which order they have to be set.
> >>
> >> - Davinci driver [5] in line 1115 checks for data line to call
> >> mmc_signal_sdio_irq() for irq enable.
> >>
> >> - Davinci driver deals with SDIO in xfer_done() (line 873)
> >>
> >> - Davinci driver sets block size to 64 if SDIO in line 701
> >>
> >> It would be quite nice if anybody likes to comment on attachment and
> >> help testing.
> >>
> >> Many thanks and best regards
> >>
> >> Dirk
> >>
> >> [1] http://gumstix.net/wiki/index.php?title=Overo_Wifi
> >>
> >> [2] http://groups.google.com/group/beagleboard/msg/14e822778c5eeb56
> >>
> >> [3] http://groups.google.com/group/beagleboard/msg/d0eb69f4c20673be
> >>
> >> [4] http://groups.google.com/group/beagleboard/msg/5cdfe2a319531937
> >>
> >> [5]
> >> http://arago-project.org/git/projects/?p=linux-
> davinci.git;a=blob;f=drivers/mmc/host/davinci_mmc.c;h=1bf0587250614c6d8abf
> e02028b96e0e47148ac8;hb=HEAD
> >>
> >> [6] http://www.sdcard.org/developers/tech/sdio/sd_bluetooth_spec/
> >>
> >> [7] http://focus.ti.com/lit/ug/spruf98c/spruf98c.pdf
> >>
> >>
> >
> >
> >
> 



  reply	other threads:[~2009-10-16 21:14 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-15 20:30 MMC_CAP_SDIO_IRQ for omap 3430 John Rigby
2009-10-16  7:16 ` Dirk Behme
2009-10-16 13:43   ` John Rigby
2009-10-16 15:02     ` Dirk Behme
2009-10-16 15:59       ` John Rigby
2009-10-16 16:06         ` Dirk Behme
2009-10-16 18:51           ` John Rigby
2009-10-16 19:55             ` Dirk Behme
     [not found]               ` <4b73d43f0910161337k24908c7bjf5d84a90efb27bef@mail.gmail.com>
2009-10-16 20:39                 ` John Rigby
2009-10-16 17:43   ` Madhusudhan Chikkature
2009-10-16 19:28     ` Dirk Behme
2009-10-16 21:14       ` Madhusudhan [this message]
2009-10-16 21:26         ` John Rigby
2009-10-17  6:30           ` Dirk Behme
2009-10-17 15:12             ` John Rigby
2009-10-17 17:36               ` Dirk Behme
2009-10-17 18:08               ` Dirk Behme
2009-10-18 16:44           ` Dirk Behme
2009-10-18 23:12             ` Woodruff, Richard
2009-10-19  0:17               ` John Rigby
     [not found]                 ` <4b73d43f0910181724q11d40851wb2aed801d7ae85f6@mail.gmail.com>
2009-10-19 17:27                   ` Madhusudhan
     [not found]                   ` <005101ca50e1$11ef2770$544ff780@am.dhcp.ti.com>
2009-10-19 18:10                     ` Dirk Behme
2009-10-19 18:16                     ` Dirk Behme
2009-10-20 22:47                       ` Madhusudhan
2009-10-20 22:59                         ` John Rigby
2009-10-21 17:46                           ` Dirk Behme
2009-10-21 17:44                         ` Dirk Behme
2009-10-20  1:13                     ` John Rigby
2009-10-20  2:53                       ` Woodruff, Richard
     [not found]                     ` <4b73d43f0910191439o30fd1de6odab8ccd5e5430760@mail.gmail.com>
2009-10-20  4:47                       ` Dirk Behme
2009-10-20 18:45                         ` John Rigby
2009-10-20 18:55                           ` Steve Sakoman
2009-10-19 14:52               ` Dirk Behme
2009-10-19 15:29                 ` Woodruff, Richard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='004701ca4ea5$aeacefe0$544ff780@am.dhcp.ti.com' \
    --to=madhu.cr@ti.com \
    --cc=dirk.behme@googlemail.com \
    --cc=jcrigby@gmail.com \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=sakoman@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox