Re: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
On Tue, Mar 2, 2010 at 2:08 PM, Madhusudhan wrote: >> That is correct, a Wi2Wi wifi module is connected via mmc2 on the >> Overo Air and Fire products. > A dumb question. Is this Wi2Wi wifi module available as a standard SDIO card > which can be plugged into a SD card cage? Or is it specifically designed for > the gumstix board? The module on Overo is soldered directly to the board. It is a standard part, not custom. I am not aware if wi2wi also sells a SD version. Steve -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
> -Original Message- > From: Steve Sakoman [mailto:sako...@gmail.com] > Sent: Thursday, February 18, 2010 4:16 PM > To: Paul Walmsley > Cc: Madhusudhan; David Vrabel; r-woodru...@ti.com; saw...@ti.com; linux- > m...@vger.kernel.org; linux-omap@vger.kernel.org > Subject: Re: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts > > On Thu, Feb 18, 2010 at 12:21 PM, Paul Walmsley wrote: > > > (cc'ing Steve, Richard, Anand) > > > There appear to be least seven SDIO card drivers in 2.6.34-rc7. At least > > one of these is for a TI chip - the wl1251. I think some of the > > Gumstix Overo OMAP3 boards are using an SDIO-connected Marvell Libertas: > > > > http://www.gumstix.com/store/catalog/product_info.php?products_id=252 > > That is correct, a Wi2Wi wifi module is connected via mmc2 on the > Overo Air and Fire products. > Steve, A dumb question. Is this Wi2Wi wifi module available as a standard SDIO card which can be plugged into a SD card cage? Or is it specifically designed for the gumstix board? Regards, Madhu > Data rates are pretty low with the existing OMAP SDIO driver. Any > chance this patch would improve that situation? > > Just added applying the patch and retesting data rates to my "to do" list > :-) > > Steve > > > David is probably testing with a Bluetooth card - maybe he can comment > > further. > > > >> And at least I don't see a way I can test any of these features myself. > > > > Could you clarify? > > > > > > - Paul > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
Madhusudhan wrote: > > A little bit of rearranging the David's changes to the irq handler gets the > MMC/SD cards to work fine again. Changes are shown in the attached patch for > now and it should not hurt the CIRQ handling as well. This breaks detecting card interrupts unless a command is in progress. >>> + status = OMAP_HSMMC_READ(host->base, STAT); >>> + OMAP_HSMMC_WRITE(host->base, STAT, status); >>> + OMAP_HSMMC_READ(host->base, STAT); /* Flush posted write. */ >>> + >>> + if (status & CIRQ) >>> + card_irq = true; >>> + >>> + if (host->mrq == NULL) >>> + goto out; >>> >>> data = host->data; >>> status = OMAP_HSMMC_READ(host->base, STAT); This line is the real problem. We re-read MMCi_STAT after acknowledging (clearing) it. Please see the version #2 of the patchset. David -- David Vrabel, Senior Software Engineer, Drivers CSR, Churchill House, Cambridge Business Park, Tel: +44 (0)1223 692562 Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/ Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
> -Original Message-
> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
> ow...@vger.kernel.org] On Behalf Of Madhusudhan
> Sent: Friday, February 19, 2010 3:05 PM
> To: 'David Vrabel'; linux-...@vger.kernel.org
> Cc: linux-omap@vger.kernel.org
> Subject: RE: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
>
>
>
> > -Original Message-
> > From: David Vrabel [mailto:david.vra...@csr.com]
> > Sent: Wednesday, February 10, 2010 5:52 AM
> > To: linux-...@vger.kernel.org
> > Cc: David Vrabel; linux-omap@vger.kernel.org; madhu...@ti.com
> > Subject: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
> >
> > Enable the use of SDIO card interrupts. This requires setting ENAWAKEUP
> > in SYSCONFIG and IWE in HTCL to allow the MMC block to wake-up when in
> > smart-idle mode.
> >
> > FCLK must be enabled while SDIO interrupts are enabled or the MMC block
> > won't wake-up.
> >
> > The writes to STAT and ISE when starting a command are unnecessary and
> > have been removed.
> >
> > Signed-off-by: David Vrabel
> > ---
> > As noted in the FIXME comment, I think the correct thing to do is to
> > always leave FCLK enabled. The clock/clockdomain subsystems should be
> > configuring smart-idle mode making explicit calls to disable FCLK
> > unnecessary. I couldn't follow the clock subsystem to see if it was
> > actually doing this, though.
>
> I Just noticed that SD cards stopped working on Zoom2 if I apply this
> patch.
> I will come back with details on what's going on in a bit unless someone
> else beats me on that.
>
A little bit of rearranging the David's changes to the irq handler gets the
MMC/SD cards to work fine again. Changes are shown in the attached patch for
now and it should not hurt the CIRQ handling as well.
Regards,
Madhu
> Regards,
> Madhu
>
>
> > ---
> > drivers/mmc/host/omap_hsmmc.c | 94 --
> --
> > -
> > 1 files changed, 65 insertions(+), 29 deletions(-)
> >
> > diff --git a/drivers/mmc/host/omap_hsmmc.c
> b/drivers/mmc/host/omap_hsmmc.c
> > index e6d8cb3..ad0f867 100644
> > --- a/drivers/mmc/host/omap_hsmmc.c
> > +++ b/drivers/mmc/host/omap_hsmmc.c
> > @@ -64,6 +64,7 @@
> > #define SDVS_MASK 0x0E00
> > #define SDVSCLR0xF1FF
> > #define SDVSDET0x0400
> > +#define ENAWAKEUP (1 << 2)
> > #define AUTOIDLE 0x1
> > #define SDBP (1 << 8)
> > #define DTO0xe
> > @@ -74,9 +75,11 @@
> > #define CLKD_SHIFT 6
> > #define DTO_MASK 0x000F
> > #define DTO_SHIFT 16
> > +#define CIRQ_ENABLE(1 << 8)
> > #define INT_EN_MASK0x307F0033
> > #define BWR_ENABLE (1 << 4)
> > #define BRR_ENABLE (1 << 5)
> > +#define CTPL (1 << 11)
> > #define INIT_STREAM(1 << 1)
> > #define DP_SELECT (1 << 21)
> > #define DDIR (1 << 4)
> > @@ -84,10 +87,12 @@
> > #define MSBS (1 << 5)
> > #define BCE(1 << 1)
> > #define FOUR_BIT (1 << 1)
> > +#define IWE(1 << 24)
> > #define DW8(1 << 5)
> > #define CC 0x1
> > #define TC 0x02
> > #define OD 0x1
> > +#define CIRQ (1 << 8)
> > #define ERR(1 << 15)
> > #define CMD_TIMEOUT(1 << 16)
> > #define DATA_TIMEOUT (1 << 20)
> > @@ -228,7 +233,7 @@ static int omap_hsmmc_context_restore(struct
> > omap_hsmmc_host *host)
> > ;
> >
> > OMAP_HSMMC_WRITE(host->base, SYSCONFIG,
> > - OMAP_HSMMC_READ(host->base, SYSCONFIG) | AUTOIDLE);
> > + OMAP_HSMMC_READ(host->base, SYSCONFIG) | AUTOIDLE |
> > ENAWAKEUP);
> >
> > if (host->id == OMAP_MMC1_DEVID) {
> > if (host->power_mode != MMC_POWER_OFF &&
> > @@ -243,7 +248,7 @@ static int omap_hsmmc_context_restore(struct
> > omap_hsmmc_host *host)
> > }
> >
> > OMAP_HSMMC_WRITE(host->base, HCTL,
> > - OMAP_HSMMC_READ(host->base, HCT
RE: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
> -Original Message- > From: Paul Walmsley [mailto:p...@pwsan.com] > Sent: Thursday, February 18, 2010 2:21 PM > To: Madhusudhan > Cc: 'David Vrabel'; sako...@gmail.com; r-woodru...@ti.com; saw...@ti.com; > linux-...@vger.kernel.org; linux-omap@vger.kernel.org > Subject: RE: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts > > Hi, > > (cc'ing Steve, Richard, Anand) > > On Thu, 18 Feb 2010, Madhusudhan wrote: > > > Not to add further confusion but as far as I understand SDIO should be > > able to asynchronously wakeup OMAP regardless of MMC clocks being OFF . > > As per the SDIO spec DAT1 line is used for signaling the card interrupt > > to the host. The TRM clearly shows a GPIO connected to DAT1 line for > > wakeup through the SDIO interrupt. Wouldn't this help? > > Is the integration code in arch/arm/*omap* set to enable wakeup on the > DAT1 ball on the OMAP? I don't see any trace of that in the code. That > would surely prevent wakeup from succeeding on an off-mode enabled kernel. > Sounds like there may be other problems. Why not give it a try with an > SDIO card and see if you can get it to work? > > > Definitely these are good features that are being added. Just that there > > are confusions around and not everyone has a setup to validate these > > features. > > Hopefully someone inside TI is validating SDIO wakeup on Linux? > > > If I look in the mainline kernel today there is only one SDIO card > > driver " sdio_uart.c". > > [p...@twilight current]$ find . -name "*sdio*c" -print | fgrep -v /core/ > ./drivers/ssb/sdio.c > ./drivers/bluetooth/btsdio.c > ./drivers/bluetooth/btmrvl_sdio.c > ./drivers/mmc/host/mvsdio.c > ./drivers/net/wimax/i2400m/sdio-rx.c > ./drivers/net/wimax/i2400m/sdio-tx.c > ./drivers/net/wimax/i2400m/sdio.c > ./drivers/net/wimax/i2400m/sdio-fw.c > ./drivers/net/wireless/iwmc3200wifi/sdio.c > ./drivers/net/wireless/libertas/if_sdio.c > ./drivers/net/wireless/wl12xx/wl1251_sdio.c > ./drivers/net/wireless/b43/sdio.c > ./drivers/media/dvb/siano/smssdio.c > [p...@twilight current]$ > > There appear to be least seven SDIO card drivers in 2.6.34-rc7. At least > one of these is for a TI chip - the wl1251. I think some of the > Gumstix Overo OMAP3 boards are using an SDIO-connected Marvell Libertas: > > http://www.gumstix.com/store/catalog/product_info.php?products_id=252 > > David is probably testing with a Bluetooth card - maybe he can comment > further. > > > And at least I don't see a way I can test any of these features myself. > > Could you clarify? > I meant that right now I am not equipped with a setup that has a SDIO device that works to a level that this wakeup feature can be validated. Regards, Madhu > > - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
> -Original Message-
> From: David Vrabel [mailto:david.vra...@csr.com]
> Sent: Wednesday, February 10, 2010 5:52 AM
> To: linux-...@vger.kernel.org
> Cc: David Vrabel; linux-omap@vger.kernel.org; madhu...@ti.com
> Subject: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
>
> Enable the use of SDIO card interrupts. This requires setting ENAWAKEUP
> in SYSCONFIG and IWE in HTCL to allow the MMC block to wake-up when in
> smart-idle mode.
>
> FCLK must be enabled while SDIO interrupts are enabled or the MMC block
> won't wake-up.
>
> The writes to STAT and ISE when starting a command are unnecessary and
> have been removed.
>
> Signed-off-by: David Vrabel
> ---
> As noted in the FIXME comment, I think the correct thing to do is to
> always leave FCLK enabled. The clock/clockdomain subsystems should be
> configuring smart-idle mode making explicit calls to disable FCLK
> unnecessary. I couldn't follow the clock subsystem to see if it was
> actually doing this, though.
I Just noticed that SD cards stopped working on Zoom2 if I apply this patch.
I will come back with details on what's going on in a bit unless someone
else beats me on that.
Regards,
Madhu
> ---
> drivers/mmc/host/omap_hsmmc.c | 94
> -
> 1 files changed, 65 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index e6d8cb3..ad0f867 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -64,6 +64,7 @@
> #define SDVS_MASK0x0E00
> #define SDVSCLR 0xF1FF
> #define SDVSDET 0x0400
> +#define ENAWAKEUP(1 << 2)
> #define AUTOIDLE 0x1
> #define SDBP (1 << 8)
> #define DTO 0xe
> @@ -74,9 +75,11 @@
> #define CLKD_SHIFT 6
> #define DTO_MASK 0x000F
> #define DTO_SHIFT16
> +#define CIRQ_ENABLE (1 << 8)
> #define INT_EN_MASK 0x307F0033
> #define BWR_ENABLE (1 << 4)
> #define BRR_ENABLE (1 << 5)
> +#define CTPL (1 << 11)
> #define INIT_STREAM (1 << 1)
> #define DP_SELECT(1 << 21)
> #define DDIR (1 << 4)
> @@ -84,10 +87,12 @@
> #define MSBS (1 << 5)
> #define BCE (1 << 1)
> #define FOUR_BIT (1 << 1)
> +#define IWE (1 << 24)
> #define DW8 (1 << 5)
> #define CC 0x1
> #define TC 0x02
> #define OD 0x1
> +#define CIRQ (1 << 8)
> #define ERR (1 << 15)
> #define CMD_TIMEOUT (1 << 16)
> #define DATA_TIMEOUT (1 << 20)
> @@ -228,7 +233,7 @@ static int omap_hsmmc_context_restore(struct
> omap_hsmmc_host *host)
> ;
>
> OMAP_HSMMC_WRITE(host->base, SYSCONFIG,
> - OMAP_HSMMC_READ(host->base, SYSCONFIG) | AUTOIDLE);
> + OMAP_HSMMC_READ(host->base, SYSCONFIG) | AUTOIDLE |
> ENAWAKEUP);
>
> if (host->id == OMAP_MMC1_DEVID) {
> if (host->power_mode != MMC_POWER_OFF &&
> @@ -243,7 +248,7 @@ static int omap_hsmmc_context_restore(struct
> omap_hsmmc_host *host)
> }
>
> OMAP_HSMMC_WRITE(host->base, HCTL,
> - OMAP_HSMMC_READ(host->base, HCTL) | hctl);
> + OMAP_HSMMC_READ(host->base, HCTL) | hctl | IWE);
>
> OMAP_HSMMC_WRITE(host->base, CAPA,
> OMAP_HSMMC_READ(host->base, CAPA) | capa);
> @@ -257,7 +262,7 @@ static int omap_hsmmc_context_restore(struct
> omap_hsmmc_host *host)
> ;
>
> OMAP_HSMMC_WRITE(host->base, STAT, STAT_CLEAR);
> - OMAP_HSMMC_WRITE(host->base, ISE, INT_EN_MASK);
> + OMAP_HSMMC_WRITE(host->base, ISE, INT_EN_MASK | CIRQ);
> OMAP_HSMMC_WRITE(host->base, IE, INT_EN_MASK);
>
> /* Do not initialize card-specific things if the power is off */
> @@ -426,12 +431,6 @@ omap_hsmmc_start_command(struct omap_hsmmc_host
> *host, struct mmc_command *cmd,
> mmc_hostname(host->mmc), cmd->opcode, cmd->arg);
> host->cmd = cmd;
>
> - /*
> - * Clear status bits and enable interrupts
> - */
> - OMAP_HSMMC_WRITE(host->base, STAT, STAT_CLEAR);
> - OMAP_HSMMC_WRITE(host->base, ISE, INT_EN_MASK);
> -
> if
Re: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
On Thu, 18 Feb 2010, Steve Sakoman wrote: > On Thu, Feb 18, 2010 at 12:21 PM, Paul Walmsley wrote: > > > (cc'ing Steve, Richard, Anand) > > > There appear to be least seven SDIO card drivers in 2.6.34-rc7. At least > > one of these is for a TI chip - the wl1251. I think some of the > > Gumstix Overo OMAP3 boards are using an SDIO-connected Marvell Libertas: > > > > http://www.gumstix.com/store/catalog/product_info.php?products_id=252 > > That is correct, a Wi2Wi wifi module is connected via mmc2 on the > Overo Air and Fire products. > > Data rates are pretty low with the existing OMAP SDIO driver. Any > chance this patch would improve that situation? Without proper SDIO interrupt support at the controller level, the core SDIO code does poll for pending SDIO interrupts periodically. So yes, this patch is certainly going to help throughput. Nicolas
Re: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
On Thu, Feb 18, 2010 at 12:21 PM, Paul Walmsley wrote: > (cc'ing Steve, Richard, Anand) > There appear to be least seven SDIO card drivers in 2.6.34-rc7. At least > one of these is for a TI chip - the wl1251. I think some of the > Gumstix Overo OMAP3 boards are using an SDIO-connected Marvell Libertas: > > http://www.gumstix.com/store/catalog/product_info.php?products_id=252 That is correct, a Wi2Wi wifi module is connected via mmc2 on the Overo Air and Fire products. Data rates are pretty low with the existing OMAP SDIO driver. Any chance this patch would improve that situation? Just added applying the patch and retesting data rates to my "to do" list :-) Steve > David is probably testing with a Bluetooth card - maybe he can comment > further. > >> And at least I don't see a way I can test any of these features myself. > > Could you clarify? > > > - Paul > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
Hi, (cc'ing Steve, Richard, Anand) On Thu, 18 Feb 2010, Madhusudhan wrote: > Not to add further confusion but as far as I understand SDIO should be > able to asynchronously wakeup OMAP regardless of MMC clocks being OFF . > As per the SDIO spec DAT1 line is used for signaling the card interrupt > to the host. The TRM clearly shows a GPIO connected to DAT1 line for > wakeup through the SDIO interrupt. Wouldn't this help? Is the integration code in arch/arm/*omap* set to enable wakeup on the DAT1 ball on the OMAP? I don't see any trace of that in the code. That would surely prevent wakeup from succeeding on an off-mode enabled kernel. Sounds like there may be other problems. Why not give it a try with an SDIO card and see if you can get it to work? > Definitely these are good features that are being added. Just that there > are confusions around and not everyone has a setup to validate these > features. Hopefully someone inside TI is validating SDIO wakeup on Linux? > If I look in the mainline kernel today there is only one SDIO card > driver " sdio_uart.c". [p...@twilight current]$ find . -name "*sdio*c" -print | fgrep -v /core/ ./drivers/ssb/sdio.c ./drivers/bluetooth/btsdio.c ./drivers/bluetooth/btmrvl_sdio.c ./drivers/mmc/host/mvsdio.c ./drivers/net/wimax/i2400m/sdio-rx.c ./drivers/net/wimax/i2400m/sdio-tx.c ./drivers/net/wimax/i2400m/sdio.c ./drivers/net/wimax/i2400m/sdio-fw.c ./drivers/net/wireless/iwmc3200wifi/sdio.c ./drivers/net/wireless/libertas/if_sdio.c ./drivers/net/wireless/wl12xx/wl1251_sdio.c ./drivers/net/wireless/b43/sdio.c ./drivers/media/dvb/siano/smssdio.c [p...@twilight current]$ There appear to be least seven SDIO card drivers in 2.6.34-rc7. At least one of these is for a TI chip - the wl1251. I think some of the Gumstix Overo OMAP3 boards are using an SDIO-connected Marvell Libertas: http://www.gumstix.com/store/catalog/product_info.php?products_id=252 David is probably testing with a Bluetooth card - maybe he can comment further. > And at least I don't see a way I can test any of these features myself. Could you clarify? - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
> -Original Message- > From: Nicolas Pitre [mailto:n...@fluxnic.net] > Sent: Thursday, February 18, 2010 1:27 PM > To: Madhusudhan > Cc: 'Paul Walmsley'; 'David Vrabel'; linux-...@vger.kernel.org; linux- > o...@vger.kernel.org > Subject: RE: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts > > On Thu, 18 Feb 2010, Madhusudhan wrote: > > > If I look in the mainline kernel today there is only one SDIO card > driver " > > sdio_uart.c". And at least I don't see a way I can test any of these > > features myself. > > There are many other SDIO drivers in the kernel today: > > - The libertas wireless driver supports many interfaces, including >PCMCIA/CF, USB, SDIO and SPI. Chips known to work with the SDIO >interface are the Marvell 8686 and 8688. > > - There is a BlueTooth HCI SDIO driver implementing the standard SDIO >BlueTooth class. > > - The Marvell 8688 mentioned above is also a BlueTooth device through >an additional SDIO "function". > > - Intel Wireless WiMAX Connection 2400 over SDIO. > > And the sdio_uart.c driver can be used with SDIO GPS receivers for > example. > This is good information. Any known SDIO cards commercially available using the above chips? Thanks, Madhu > > Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
On Thu, 18 Feb 2010, Madhusudhan wrote: > If I look in the mainline kernel today there is only one SDIO card driver " > sdio_uart.c". And at least I don't see a way I can test any of these > features myself. There are many other SDIO drivers in the kernel today: - The libertas wireless driver supports many interfaces, including PCMCIA/CF, USB, SDIO and SPI. Chips known to work with the SDIO interface are the Marvell 8686 and 8688. - There is a BlueTooth HCI SDIO driver implementing the standard SDIO BlueTooth class. - The Marvell 8688 mentioned above is also a BlueTooth device through an additional SDIO "function". - Intel Wireless WiMAX Connection 2400 over SDIO. And the sdio_uart.c driver can be used with SDIO GPS receivers for example. Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
> -Original Message- > From: Paul Walmsley [mailto:p...@pwsan.com] > Sent: Thursday, February 18, 2010 11:44 AM > To: David Vrabel > Cc: Madhusudhan; linux-...@vger.kernel.org; linux-omap@vger.kernel.org > Subject: Re: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts > > On Thu, 18 Feb 2010, David Vrabel wrote: > > > Paul Walmsley wrote: > > > > > > Perhaps I'm misunderstanding what you're referring to, but it seems > there > > > is some confusion as to what target smart-idle mode does. > > > > The TI OMAP 34xx TRM is the one of the most obtuse document I've had to > > read. An even after multiple reads of relevant sections it still > > doesn't make sense. Parts are contradictory, parts are poorly explained > > and some bit are just plain incorrect. > > Yes. TI needs to also release the functional specifications for each IP > block; the information in the current TRM is generally insufficient to > write high-quality drivers. > > TI should also host a process, open to the public, to submit TRM revision > and clarification requests, and to track their disposition. > Paul, David, Not to add further confusion but as far as I understand SDIO should be able to asynchronously wakeup OMAP regardless of MMC clocks being OFF . As per the SDIO spec DAT1 line is used for signaling the card interrupt to the host. The TRM clearly shows a GPIO connected to DAT1 line for wakeup through the SDIO interrupt. Wouldn't this help? > > I don't have time to sort out any of this properly -- it works well > > enough for me. > > Thanks very much for the SDIO patches. They are appreciated. Definitely these are good features that are being added. Just that there are confusions around and not everyone has a setup to validate these features. If I look in the mainline kernel today there is only one SDIO card driver " sdio_uart.c". And at least I don't see a way I can test any of these features myself. Regards, Madhu > > > - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
On Thu, 18 Feb 2010, David Vrabel wrote: > Paul Walmsley wrote: > > > > Perhaps I'm misunderstanding what you're referring to, but it seems there > > is some confusion as to what target smart-idle mode does. > > The TI OMAP 34xx TRM is the one of the most obtuse document I've had to > read. An even after multiple reads of relevant sections it still > doesn't make sense. Parts are contradictory, parts are poorly explained > and some bit are just plain incorrect. Yes. TI needs to also release the functional specifications for each IP block; the information in the current TRM is generally insufficient to write high-quality drivers. TI should also host a process, open to the public, to submit TRM revision and clarification requests, and to track their disposition. > I don't have time to sort out any of this properly -- it works well > enough for me. Thanks very much for the SDIO patches. They are appreciated. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
> -Original Message- > From: David Vrabel [mailto:david.vra...@csr.com] > Sent: Thursday, February 18, 2010 6:16 AM > To: Madhusudhan > Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org > Subject: Re: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts > > Madhusudhan wrote: > > > > My question was more related to the idle path. In a scenario where > > you start using the SDIO functionality and after some time you leave > > the SDIO card idle, does the FCLK still remain enabled? Or do you see > > that sdio_irq_thread exits and disables the FCLK? > > What do you mean by "leave the SDIO card idle"? > I meant a state where the SDIO card is not doing any active transfers. Does it work that way? Regards, Madhu > David > -- > David Vrabel, Senior Software Engineer, Drivers > CSR, Churchill House, Cambridge Business Park, Tel: +44 (0)1223 692562 > Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/ > > > Member of the CSR plc group of companies. CSR plc registered in England > and Wales, registered number 4187346, registered office Churchill House, > Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
Paul Walmsley wrote: > > Perhaps I'm misunderstanding what you're referring to, but it seems there > is some confusion as to what target smart-idle mode does. The TI OMAP 34xx TRM is the one of the most obtuse document I've had to read. An even after multiple reads of relevant sections it still doesn't make sense. Parts are contradictory, parts are poorly explained and some bit are just plain incorrect. I don't have time to sort out any of this properly -- it works well enough for me. David -- David Vrabel, Senior Software Engineer, Drivers CSR, Churchill House, Cambridge Business Park, Tel: +44 (0)1223 692562 Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/ Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
Madhusudhan wrote: > > My question was more related to the idle path. In a scenario where > you start using the SDIO functionality and after some time you leave > the SDIO card idle, does the FCLK still remain enabled? Or do you see > that sdio_irq_thread exits and disables the FCLK? What do you mean by "leave the SDIO card idle"? David -- David Vrabel, Senior Software Engineer, Drivers CSR, Churchill House, Cambridge Business Park, Tel: +44 (0)1223 692562 Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/ Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
> -Original Message- > From: David Vrabel [mailto:david.vra...@csr.com] > Sent: Wednesday, February 17, 2010 1:40 PM > To: Madhusudhan > Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org > Subject: Re: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts > > Madhusudhan wrote: > > > >> -Original Message- > >> From: David Vrabel [mailto:david.vra...@csr.com] > >> Sent: Wednesday, February 10, 2010 5:52 AM > >> To: linux-...@vger.kernel.org > >> Cc: David Vrabel; linux-omap@vger.kernel.org; madhu...@ti.com > >> Subject: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts > >> > >> Enable the use of SDIO card interrupts. This requires setting > ENAWAKEUP > >> in SYSCONFIG and IWE in HTCL to allow the MMC block to wake-up when in > >> smart-idle mode. > >> > >> FCLK must be enabled while SDIO interrupts are enabled or the MMC block > >> won't wake-up. > >> > > > > I am curious to know the system behavior with this patch. Does the FCLK > > remain enabled forever if a SDIO card is detected on the bus? > > Only if card interrupts are enabled. The card irq is disabled when the > sdio_irq_thread exits. > Your patch sets up the capability to enable sdio irqs anyway. My question was more related to the idle path. In a scenario where you start using the SDIO functionality and after some time you leave the SDIO card idle, does the FCLK still remain enabled? Or do you see that sdio_irq_thread exits and disables the FCLK? Regards, Madhu > This is why I think that smart-idle mode needs to be used (it's turned > on by default on the MMC controller) but I don't understand the > clock/clockdomain code to see if that's doing the right thing. > > If smart-idle mode is used then we don't need to disable FCLK manually > to save power. This will simplify the driver a bit. > > David -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
>From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
>ow...@vger.kernel.org] On Behalf Of David Vrabel
>Sent: Wednesday, February 17, 2010 7:10 PM
>
>David Vrabel wrote:
>>
>> +static void omap_hsmmc_enable_sdio_irq(struct mmc_host *mmc, int enable)
>> +{
>> +struct omap_hsmmc_host *host = mmc_priv(mmc);
>> +u32 ie, con;
>> +unsigned long flags;
>> +
>> +spin_lock_irqsave(&host->irq_lock, flags);
>> +
>> +/*
>> + * When interrupts are enabled, CTPL must be set to enable
>> + * DAT1 input buffer (or the card interrupt is always
>> + * asserted) and FCLK must be enabled else wakeup does not
>> + * work.
>> + *
>> + * FIXME: the power save code probably shouldn't be playing
>> + * with FCLK and allow the clock subsystem to put it into
>> + * smart-idle mode instead.
>> + */
>> +con = OMAP_HSMMC_READ(host->base, CON);
>> +ie = OMAP_HSMMC_READ(host->base, IE);
>> +if (enable) {
>> +clk_enable(host->fclk);
>> +ie |= CIRQ_ENABLE;
>> +con |= CTPL;
>> +} else {
>> +clk_disable(host->fclk);
>> +ie &= ~CIRQ_ENABLE;
>> +con &= ~CTPL;
>> +}
>> +OMAP_HSMMC_WRITE(host->base, CON, con);
>> +OMAP_HSMMC_WRITE(host->base, IE, ie);
>> +
>> +spin_unlock_irqrestore(&host->irq_lock, flags);
>> +}
>
>This isn't doing a posted write flush but when it's added this ends up
>looking like:
>
> spin_lock_irqsave(&host->lock, flags);
>
> /*
>* When interrupts are enabled, CTPL must be set to enable
>* DAT1 input buffer (or the card interrupt is always
>* asserted) and FCLK must be enabled else wakeup does not
>* work. Take care to disable FCLK after all the register
>* accesses as they might not complete if FCLK is off.
>*
>* FIXME: the power save code probably shouldn't be playing
>* with FCLK and allow the clock subsystem to put it into
>* smart-idle mode instead.
>*/
> con = OMAP_HSMMC_READ(host->base, CON);
> ie = OMAP_HSMMC_READ(host->base, IE);
> if (enable) {
> clk_enable(host->fclk);
> ie |= CIRQ_ENABLE;
> con |= CTPL;
> } else {
> ie &= ~CIRQ_ENABLE;
> con &= ~CTPL;
> }
> OMAP_HSMMC_WRITE(host->base, CON, con);
> OMAP_HSMMC_WRITE(host->base, IE, ie);
> OMAP_HSMMC_READ(host->base, IE); /* flush posted write */
>if (!enable) {
>clk_disable(host->fclk);
>}
>
> spin_unlock_irqrestore(&host->lock, flags);
>
>Could someone from TI could comment on why disabling FCLK affects
>register read?
Most IPs will require both iclk and fclk to be active in order to access them.
Some simple IP can work with only an iclk.
Otherwise, accessing a register while enabling only iclk will lead to
unpredictable behavior.
Regards,
Benoit
Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet.
036 420 040 R.C.S Antibes. Capital de EUR 753.920
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
On Wed, 17 Feb 2010, David Vrabel wrote: > Madhusudhan wrote: > > > > > -Original Message- > > > From: David Vrabel [mailto:david.vra...@csr.com] > > > Sent: Wednesday, February 10, 2010 5:52 AM > > > To: linux-...@vger.kernel.org > > > Cc: David Vrabel; linux-omap@vger.kernel.org; madhu...@ti.com > > > Subject: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts > > > > > > Enable the use of SDIO card interrupts. This requires setting ENAWAKEUP > > > in SYSCONFIG and IWE in HTCL to allow the MMC block to wake-up when in > > > smart-idle mode. > > > > > > FCLK must be enabled while SDIO interrupts are enabled or the MMC block > > > won't wake-up. > > > > > > > I am curious to know the system behavior with this patch. Does the FCLK > > remain enabled forever if a SDIO card is detected on the bus? > > Only if card interrupts are enabled. The card irq is disabled when the > sdio_irq_thread exits. > > This is why I think that smart-idle mode needs to be used (it's turned > on by default on the MMC controller) but I don't understand the > clock/clockdomain code to see if that's doing the right thing. The easiest way to observe the operation of the clock and clockdomain code is to change the "#undef DEBUG" to "#define DEBUG" at the top of the clock or clockdomain code files that you're interested in observing, recompile the kernel, and boot it. You'll want to use an "ignore_loglevel" kernel command line parameter or something similar. This will alter the behavior of some power management situations, since the output of the debug messages will keep a UART active, but should be sufficient for the MMC work. > If smart-idle mode is used then we don't need to disable FCLK manually to save > power. This will simplify the driver a bit. Perhaps I'm misunderstanding what you're referring to, but it seems there is some confusion as to what target smart-idle mode does. It's the PRCM that requests that the module enter idle. This process is not dependent on the target idle mode bits, and happens when the PRCM concludes that clocks can potentially be disabled. In the case of functional clocks, this process is triggered when some code (i.e., the clock code) disables the CM_FCLKEN_x.EN_y bit. After the PRCM requests the module enter idle, depending on the OCP_SYSCONFIG.SIDLEMODE bits, the module either does not acknowledge the idle request (no-idle mode), always acknowledges the request (force-idle mode), or, acknowledges the idle request when the module believes it is internally quiescent (smart-idle mode). This acknowledgement signal originates from the module and goes back to the PRCM. Once this happens, the PRCM can switch off some clocks. As can be seen in the HSMMC TRM docs, the HSMMC module expects the PRCM to disable both the interface and the functional clock when it acknowledges the idle request. My point is that the target idle mode is unlikely to have any impact on the need to disable and enable the functional clock in software. That said, I don't really know the details of the SDIO wakeup issue that you mention, but it might be worth observing that if your SDIO card doesn't generate its own internal clock, then it's unlikely to be able to provide an interrupt to wake up the controller when the HSMMC functional clock is off. This is because the only other available clock for the card would come from the HSMMC's functional clock. It seems to me that this issue could be diagnosed fairly easily by triggering the SDIO interrupt line by hand while the HSMMC functional clock is kept off. If a wakeup is generated, then it's a card issue. Otherwise, you'll need to do some more intensive diagnostics. For example, if the CORE powerdomain isn't on when you do the test, presumably you'll need to make sure that an IO ring wakeup is set for the SDIO card's interrupt line. (In these situations, the interrupt response latency will be quite high, since the chip will need to boot from off-mode. The driver can request a lower bound on the interrupt response latency via an OMAP PM layer function, which will likely keep the chip from entering off mode.) But if the CORE powerdomain is on or in retention when you do the test, then perhaps there is indeed some issue with the HSMMC controller where it cannot generate wakeups when its functional clock is off. You'd want to verify that your HSMMC register settings are correct, though, before coming to that conclusion. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
Madhusudhan wrote: -Original Message- From: David Vrabel [mailto:david.vra...@csr.com] Sent: Wednesday, February 10, 2010 5:52 AM To: linux-...@vger.kernel.org Cc: David Vrabel; linux-omap@vger.kernel.org; madhu...@ti.com Subject: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts Enable the use of SDIO card interrupts. This requires setting ENAWAKEUP in SYSCONFIG and IWE in HTCL to allow the MMC block to wake-up when in smart-idle mode. FCLK must be enabled while SDIO interrupts are enabled or the MMC block won't wake-up. I am curious to know the system behavior with this patch. Does the FCLK remain enabled forever if a SDIO card is detected on the bus? Only if card interrupts are enabled. The card irq is disabled when the sdio_irq_thread exits. This is why I think that smart-idle mode needs to be used (it's turned on by default on the MMC controller) but I don't understand the clock/clockdomain code to see if that's doing the right thing. If smart-idle mode is used then we don't need to disable FCLK manually to save power. This will simplify the driver a bit. David -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
> -Original Message-
> From: David Vrabel [mailto:david.vra...@csr.com]
> Sent: Wednesday, February 10, 2010 5:52 AM
> To: linux-...@vger.kernel.org
> Cc: David Vrabel; linux-omap@vger.kernel.org; madhu...@ti.com
> Subject: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
>
> Enable the use of SDIO card interrupts. This requires setting ENAWAKEUP
> in SYSCONFIG and IWE in HTCL to allow the MMC block to wake-up when in
> smart-idle mode.
>
> FCLK must be enabled while SDIO interrupts are enabled or the MMC block
> won't wake-up.
>
I am curious to know the system behavior with this patch. Does the FCLK
remain enabled forever if a SDIO card is detected on the bus?
The "mmc_signal_sdio_irq" fn seems to disable the irq and then wake up the
sdio_irq_thread which would result in enabling the FCLK back. Hence the
above question.
> The writes to STAT and ISE when starting a command are unnecessary and
> have been removed.
>
> Signed-off-by: David Vrabel
> ---
> As noted in the FIXME comment, I think the correct thing to do is to
> always leave FCLK enabled. The clock/clockdomain subsystems should be
> configuring smart-idle mode making explicit calls to disable FCLK
> unnecessary. I couldn't follow the clock subsystem to see if it was
> actually doing this, though.
> ---
> drivers/mmc/host/omap_hsmmc.c | 94
> -
> 1 files changed, 65 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index e6d8cb3..ad0f867 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -64,6 +64,7 @@
> #define SDVS_MASK0x0E00
> #define SDVSCLR 0xF1FF
> #define SDVSDET 0x0400
> +#define ENAWAKEUP(1 << 2)
> #define AUTOIDLE 0x1
> #define SDBP (1 << 8)
> #define DTO 0xe
> @@ -74,9 +75,11 @@
> #define CLKD_SHIFT 6
> #define DTO_MASK 0x000F
> #define DTO_SHIFT16
> +#define CIRQ_ENABLE (1 << 8)
> #define INT_EN_MASK 0x307F0033
> #define BWR_ENABLE (1 << 4)
> #define BRR_ENABLE (1 << 5)
> +#define CTPL (1 << 11)
> #define INIT_STREAM (1 << 1)
> #define DP_SELECT(1 << 21)
> #define DDIR (1 << 4)
> @@ -84,10 +87,12 @@
> #define MSBS (1 << 5)
> #define BCE (1 << 1)
> #define FOUR_BIT (1 << 1)
> +#define IWE (1 << 24)
> #define DW8 (1 << 5)
> #define CC 0x1
> #define TC 0x02
> #define OD 0x1
> +#define CIRQ (1 << 8)
> #define ERR (1 << 15)
> #define CMD_TIMEOUT (1 << 16)
> #define DATA_TIMEOUT (1 << 20)
> @@ -228,7 +233,7 @@ static int omap_hsmmc_context_restore(struct
> omap_hsmmc_host *host)
> ;
>
> OMAP_HSMMC_WRITE(host->base, SYSCONFIG,
> - OMAP_HSMMC_READ(host->base, SYSCONFIG) | AUTOIDLE);
> + OMAP_HSMMC_READ(host->base, SYSCONFIG) | AUTOIDLE |
> ENAWAKEUP);
>
> if (host->id == OMAP_MMC1_DEVID) {
> if (host->power_mode != MMC_POWER_OFF &&
> @@ -243,7 +248,7 @@ static int omap_hsmmc_context_restore(struct
> omap_hsmmc_host *host)
> }
>
> OMAP_HSMMC_WRITE(host->base, HCTL,
> - OMAP_HSMMC_READ(host->base, HCTL) | hctl);
> + OMAP_HSMMC_READ(host->base, HCTL) | hctl | IWE);
>
> OMAP_HSMMC_WRITE(host->base, CAPA,
> OMAP_HSMMC_READ(host->base, CAPA) | capa);
> @@ -257,7 +262,7 @@ static int omap_hsmmc_context_restore(struct
> omap_hsmmc_host *host)
> ;
>
> OMAP_HSMMC_WRITE(host->base, STAT, STAT_CLEAR);
> - OMAP_HSMMC_WRITE(host->base, ISE, INT_EN_MASK);
> + OMAP_HSMMC_WRITE(host->base, ISE, INT_EN_MASK | CIRQ);
> OMAP_HSMMC_WRITE(host->base, IE, INT_EN_MASK);
>
> /* Do not initialize card-specific things if the power is off */
> @@ -426,12 +431,6 @@ omap_hsmmc_start_command(struct omap_hsmmc_host
> *host, struct mmc_command *cmd,
> mmc_hostname(host->mmc), cmd->opcode, cmd->arg);
> host->cmd = cmd;
>
> - /*
> - * Clear status bits and enable interrupts
> - */
> - OMAP_HSMMC_WRITE(host-&g
Re: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
David Vrabel wrote:
>
> +static void omap_hsmmc_enable_sdio_irq(struct mmc_host *mmc, int enable)
> +{
> + struct omap_hsmmc_host *host = mmc_priv(mmc);
> + u32 ie, con;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&host->irq_lock, flags);
> +
> + /*
> + * When interrupts are enabled, CTPL must be set to enable
> + * DAT1 input buffer (or the card interrupt is always
> + * asserted) and FCLK must be enabled else wakeup does not
> + * work.
> + *
> + * FIXME: the power save code probably shouldn't be playing
> + * with FCLK and allow the clock subsystem to put it into
> + * smart-idle mode instead.
> + */
> + con = OMAP_HSMMC_READ(host->base, CON);
> + ie = OMAP_HSMMC_READ(host->base, IE);
> + if (enable) {
> + clk_enable(host->fclk);
> + ie |= CIRQ_ENABLE;
> + con |= CTPL;
> + } else {
> + clk_disable(host->fclk);
> + ie &= ~CIRQ_ENABLE;
> + con &= ~CTPL;
> + }
> + OMAP_HSMMC_WRITE(host->base, CON, con);
> + OMAP_HSMMC_WRITE(host->base, IE, ie);
> +
> + spin_unlock_irqrestore(&host->irq_lock, flags);
> +}
This isn't doing a posted write flush but when it's added this ends up
looking like:
spin_lock_irqsave(&host->lock, flags);
/*
* When interrupts are enabled, CTPL must be set to enable
* DAT1 input buffer (or the card interrupt is always
* asserted) and FCLK must be enabled else wakeup does not
* work. Take care to disable FCLK after all the register
* accesses as they might not complete if FCLK is off.
*
* FIXME: the power save code probably shouldn't be playing
* with FCLK and allow the clock subsystem to put it into
* smart-idle mode instead.
*/
con = OMAP_HSMMC_READ(host->base, CON);
ie = OMAP_HSMMC_READ(host->base, IE);
if (enable) {
clk_enable(host->fclk);
ie |= CIRQ_ENABLE;
con |= CTPL;
} else {
ie &= ~CIRQ_ENABLE;
con &= ~CTPL;
}
OMAP_HSMMC_WRITE(host->base, CON, con);
OMAP_HSMMC_WRITE(host->base, IE, ie);
OMAP_HSMMC_READ(host->base, IE); /* flush posted write */
if (!enable) {
clk_disable(host->fclk);
}
spin_unlock_irqrestore(&host->lock, flags);
Could someone from TI could comment on why disabling FCLK affects
register read?
David
--
David Vrabel, Senior Software Engineer, Drivers
CSR, Churchill House, Cambridge Business Park, Tel: +44 (0)1223 692562
Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/
Member of the CSR plc group of companies. CSR plc registered in England and
Wales, registered number 4187346, registered office Churchill House, Cambridge
Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
Enable the use of SDIO card interrupts. This requires setting ENAWAKEUP
in SYSCONFIG and IWE in HTCL to allow the MMC block to wake-up when in
smart-idle mode.
FCLK must be enabled while SDIO interrupts are enabled or the MMC block
won't wake-up.
The writes to STAT and ISE when starting a command are unnecessary and
have been removed.
Signed-off-by: David Vrabel
---
As noted in the FIXME comment, I think the correct thing to do is to
always leave FCLK enabled. The clock/clockdomain subsystems should be
configuring smart-idle mode making explicit calls to disable FCLK
unnecessary. I couldn't follow the clock subsystem to see if it was
actually doing this, though.
---
drivers/mmc/host/omap_hsmmc.c | 94 -
1 files changed, 65 insertions(+), 29 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index e6d8cb3..ad0f867 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -64,6 +64,7 @@
#define SDVS_MASK 0x0E00
#define SDVSCLR0xF1FF
#define SDVSDET0x0400
+#define ENAWAKEUP (1 << 2)
#define AUTOIDLE 0x1
#define SDBP (1 << 8)
#define DTO0xe
@@ -74,9 +75,11 @@
#define CLKD_SHIFT 6
#define DTO_MASK 0x000F
#define DTO_SHIFT 16
+#define CIRQ_ENABLE(1 << 8)
#define INT_EN_MASK0x307F0033
#define BWR_ENABLE (1 << 4)
#define BRR_ENABLE (1 << 5)
+#define CTPL (1 << 11)
#define INIT_STREAM(1 << 1)
#define DP_SELECT (1 << 21)
#define DDIR (1 << 4)
@@ -84,10 +87,12 @@
#define MSBS (1 << 5)
#define BCE(1 << 1)
#define FOUR_BIT (1 << 1)
+#define IWE(1 << 24)
#define DW8(1 << 5)
#define CC 0x1
#define TC 0x02
#define OD 0x1
+#define CIRQ (1 << 8)
#define ERR(1 << 15)
#define CMD_TIMEOUT(1 << 16)
#define DATA_TIMEOUT (1 << 20)
@@ -228,7 +233,7 @@ static int omap_hsmmc_context_restore(struct
omap_hsmmc_host *host)
;
OMAP_HSMMC_WRITE(host->base, SYSCONFIG,
- OMAP_HSMMC_READ(host->base, SYSCONFIG) | AUTOIDLE);
+ OMAP_HSMMC_READ(host->base, SYSCONFIG) | AUTOIDLE |
ENAWAKEUP);
if (host->id == OMAP_MMC1_DEVID) {
if (host->power_mode != MMC_POWER_OFF &&
@@ -243,7 +248,7 @@ static int omap_hsmmc_context_restore(struct
omap_hsmmc_host *host)
}
OMAP_HSMMC_WRITE(host->base, HCTL,
- OMAP_HSMMC_READ(host->base, HCTL) | hctl);
+ OMAP_HSMMC_READ(host->base, HCTL) | hctl | IWE);
OMAP_HSMMC_WRITE(host->base, CAPA,
OMAP_HSMMC_READ(host->base, CAPA) | capa);
@@ -257,7 +262,7 @@ static int omap_hsmmc_context_restore(struct
omap_hsmmc_host *host)
;
OMAP_HSMMC_WRITE(host->base, STAT, STAT_CLEAR);
- OMAP_HSMMC_WRITE(host->base, ISE, INT_EN_MASK);
+ OMAP_HSMMC_WRITE(host->base, ISE, INT_EN_MASK | CIRQ);
OMAP_HSMMC_WRITE(host->base, IE, INT_EN_MASK);
/* Do not initialize card-specific things if the power is off */
@@ -426,12 +431,6 @@ omap_hsmmc_start_command(struct omap_hsmmc_host *host,
struct mmc_command *cmd,
mmc_hostname(host->mmc), cmd->opcode, cmd->arg);
host->cmd = cmd;
- /*
-* Clear status bits and enable interrupts
-*/
- OMAP_HSMMC_WRITE(host->base, STAT, STAT_CLEAR);
- OMAP_HSMMC_WRITE(host->base, ISE, INT_EN_MASK);
-
if (host->use_dma)
OMAP_HSMMC_WRITE(host->base, IE,
INT_EN_MASK & ~(BRR_ENABLE | BWR_ENABLE));
@@ -638,18 +637,21 @@ static irqreturn_t omap_hsmmc_irq(int irq, void *dev_id)
{
struct omap_hsmmc_host *host = dev_id;
struct mmc_data *data;
- int end_cmd = 0, end_trans = 0, status;
+ u32 status;
+ int end_cmd = 0, end_trans = 0;
+ bool card_irq = false;
spin_lock(&host->irq_lock);
- if (host->mrq == NULL) {
- OMAP_HSMMC_WRITE(host->base, STAT,
- OMAP_HSMMC_READ(host->base, STAT));
- /* Flush posted write */
- OMAP_HSMMC_READ(host->base, STAT);
- spin_unlock(&host->irq_lock);
- return IRQ_HANDLED;
- }
+ status = OMAP_HSMMC_READ(host->base, STAT);
+ OMAP_HSMMC_WRITE(host->base, STAT, status);
+ OMAP_HSMMC_READ(host->base, STAT); /* Flush posted write. */
+
+ if (status & CIRQ)
+ card_irq = true;
+
+ if (host->mrq == NULL)
+ goto o
