Re: MMC_CAP_SDIO_IRQ for omap 3430
Madhusudhan wrote: -Original Message- From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc- ow...@vger.kernel.org] On Behalf Of Dirk Behme Sent: Monday, October 19, 2009 1:17 PM To: linux-omap@vger.kernel.org Cc: Madhusudhan; 'John Rigby'; 'Woodruff, Richard'; linux- m...@vger.kernel.org; 'Steve Sakoman' Subject: Re: MMC_CAP_SDIO_IRQ for omap 3430 Madhusudhan wrote: Hi John, So does the SDIO card interrupt mode work fine now? (wrong attachment in previous mail :( sorry) If somebody likes to test, my updated patch v2 in attachment. Compile tested only, testing and comments are welcome. Can you inline the v2 patch please? It helps review. I don't think it is already ready for review. We are still in the find out how to get sdio irq working phase. Once we have found out what's needed for this, sure, I will send a patch for review inlined. Best regards Dirk I wonder in the version that John tested was the CTPL bit set in set_ios or enable_sdio_irq? Regards, Madhu Cheers Dirk _ From: John Rigby [mailto:jcri...@gmail.com] Sent: Sunday, October 18, 2009 7:24 PM To: Woodruff, Richard Cc: Dirk Behme; Chikkature Rajashekar, Madhusudhan; linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Steve Sakoman Subject: Re: MMC_CAP_SDIO_IRQ for omap 3430 Ok I was going to ask where you found that but I just rechecked the TRM and there it is in plain site: When this bit is set to 1, the host controller automatically disables all the input buffers except the buffer of mmci_dat[1] outside of a transaction in order to detect asynchronous card interrupt on mmci_dat[1] line and minimize the leakage current of the buffers. In my defence, I did search the TRM for every occurance of dat1 but not dat[1]. Oh well live and learn and forget and repeat. John On Sun, Oct 18, 2009 at 6:17 PM, John Rigby jcri...@gmail.com wrote: Richard, MMCHS_CON.CPTL = 1 Don't disable input buffer on DAT1 after completion to allow seeing SDIO interrupt Sounds exactly like what we need. Thanks John On Sun, Oct 18, 2009 at 5:12 PM, Woodruff, Richard r-woodru...@ti.com wrote: From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Dirk Behme Sent: Sunday, October 18, 2009 11:45 AM It would be funny if the TRM was wrong and the CIRQ bit is really cleared by writing 1 to it. I'll try that. A while back I hunted down a few of the bits for this. Maybe this will help some. SYSCONFIG.ENAWAKEUP = 1 allow ocp wrapper to generate an interrupt to prcm MMCHS_HCTL.IWE = 1 route wake up to module ocp wrapper MMCHS_CON.CPTL = 1 Don't disable input buffer on DAT1 after completion to allow seeing SDIO interrupt MMCHS_HCTL.IWE MMCHS_ISE.CIRQ_ENABLE bit to write to enable interrupt at pin MMCHS_STATbit to write for clear of SDIO interrupt R - IRQ_ENABLE (think host stack will do this) Regards, Richard W. -- 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: MMC_CAP_SDIO_IRQ for omap 3430
John Rigby wrote: In enable_sdio_irq if enable set ctpl else clear ctpl It would really help avoiding mails like this if you just would send your changes. We know that they are for an old kernel and just a dirty hack. Dirk On Tue, Oct 20, 2009 at 4:47 PM, Madhusudhan madhu...@ti.com wrote: -Original Message- From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc- ow...@vger.kernel.org] On Behalf Of Dirk Behme Sent: Monday, October 19, 2009 1:17 PM To: linux-omap@vger.kernel.org Cc: Madhusudhan; 'John Rigby'; 'Woodruff, Richard'; linux- m...@vger.kernel.org; 'Steve Sakoman' Subject: Re: MMC_CAP_SDIO_IRQ for omap 3430 Madhusudhan wrote: Hi John, So does the SDIO card interrupt mode work fine now? (wrong attachment in previous mail :( sorry) If somebody likes to test, my updated patch v2 in attachment. Compile tested only, testing and comments are welcome. Can you inline the v2 patch please? It helps review. I wonder in the version that John tested was the CTPL bit set in set_ios or enable_sdio_irq? Regards, Madhu Cheers Dirk _ From: John Rigby [mailto:jcri...@gmail.com] Sent: Sunday, October 18, 2009 7:24 PM To: Woodruff, Richard Cc: Dirk Behme; Chikkature Rajashekar, Madhusudhan; linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Steve Sakoman Subject: Re: MMC_CAP_SDIO_IRQ for omap 3430 Ok I was going to ask where you found that but I just rechecked the TRM and there it is in plain site: When this bit is set to 1, the host controller automatically disables all the input buffers except the buffer of mmci_dat[1] outside of a transaction in order to detect asynchronous card interrupt on mmci_dat[1] line and minimize the leakage current of the buffers. In my defence, I did search the TRM for every occurance of dat1 but not dat[1]. Oh well live and learn and forget and repeat. John On Sun, Oct 18, 2009 at 6:17 PM, John Rigby jcri...@gmail.com wrote: Richard, MMCHS_CON.CPTL = 1 Don't disable input buffer on DAT1 after completion to allow seeing SDIO interrupt Sounds exactly like what we need. Thanks John On Sun, Oct 18, 2009 at 5:12 PM, Woodruff, Richard r-woodru...@ti.com wrote: From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Dirk Behme Sent: Sunday, October 18, 2009 11:45 AM It would be funny if the TRM was wrong and the CIRQ bit is really cleared by writing 1 to it. I'll try that. A while back I hunted down a few of the bits for this. Maybe this will help some. SYSCONFIG.ENAWAKEUP = 1 allow ocp wrapper to generate an interrupt to prcm MMCHS_HCTL.IWE = 1 route wake up to module ocp wrapper MMCHS_CON.CPTL = 1 Don't disable input buffer on DAT1 after completion to allow seeing SDIO interrupt MMCHS_HCTL.IWE MMCHS_ISE.CIRQ_ENABLE bit to write to enable interrupt at pin MMCHS_STATbit to write for clear of SDIO interrupt R - IRQ_ENABLE (think host stack will do this) Regards, Richard W. -- 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: MMC_CAP_SDIO_IRQ for omap 3430
It is still a work in progress because I have hacked the sdio_irq thread to poll all the time. I won't get a chance to do a proper fix for a couple of days at least. The main part of the fix was just turning on the cptl in the same place you turn on the cirq bit. Send me a reminder If you get no offers of testing help from anyone else and I'll try to use my beagle board and wifi card with a modern kernel. John On Mon, Oct 19, 2009 at 10:47 PM, Dirk Behme dirk.be...@googlemail.com wrote: John Rigby wrote: All, Sorry for the delay, I have been without internet access until just now. I added the cptl bit and I don't get continuous cirqs anymore. Right now I have a hacked driver that still does timed polling in sdio_irq.c and also wakes up on cirq. With this config the libertas works well. A flood ping of 1000 packets loses 2. Previously it was dropping about 30% of the packets from a flood ping. Great!! :) Without the polling in sdio_irq.c I get timeouts in libertas driver so I suspect that we may need to add checks of the DAT1 line in other places like the davinci driver does. As I said before, my kernel is a few months old so my issues may not be the same as current head of tree. Do you like to send your changes anyway? Just for reference... Thanks to all who helped on this. Now, the job will be to do this with recent kernel, make it stable and in the mid term get it applied. Anybody likes to help with this? Many thanks and best regards Dirk On Mon, Oct 19, 2009 at 11:24 AM, Madhusudhan madhu...@ti.com wrote: Hi John, So does the SDIO card interrupt mode work fine now? Regards, Madhu -- *From:* John Rigby [mailto:jcri...@gmail.com] *Sent:* Sunday, October 18, 2009 7:24 PM *To:* Woodruff, Richard *Cc:* Dirk Behme; Chikkature Rajashekar, Madhusudhan; linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Steve Sakoman *Subject:* Re: MMC_CAP_SDIO_IRQ for omap 3430 Ok I was going to ask where you found that but I just rechecked the TRM and there it is in plain site: When this bit is set to 1, the host controller automatically disables all the input buffers except the buffer of mmci_dat[1] outside of a transaction in order to detect asynchronous card interrupt on mmci_dat[1] line and minimize the leakage current of the buffers. In my defence, I did search the TRM for every occurance of dat1 but not dat[1]. Oh well live and learn and forget and repeat. John On Sun, Oct 18, 2009 at 6:17 PM, John Rigby jcri...@gmail.com wrote: Richard, MMCHS_CON.CPTL = 1 Don't disable input buffer on DAT1 after completion to allow seeing SDIO interrupt Sounds exactly like what we need. Thanks John On Sun, Oct 18, 2009 at 5:12 PM, Woodruff, Richard r-woodru...@ti.com wrote: From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Dirk Behme Sent: Sunday, October 18, 2009 11:45 AM It would be funny if the TRM was wrong and the CIRQ bit is really cleared by writing 1 to it. I'll try that. A while back I hunted down a few of the bits for this. Maybe this will help some. SYSCONFIG.ENAWAKEUP = 1 allow ocp wrapper to generate an interrupt to prcm MMCHS_HCTL.IWE = 1 route wake up to module ocp wrapper MMCHS_CON.CPTL = 1 Don't disable input buffer on DAT1 after completion to allow seeing SDIO interrupt MMCHS_HCTL.IWE MMCHS_ISE.CIRQ_ENABLE bit to write to enable interrupt at pin MMCHS_STATbit to write for clear of SDIO interrupt R - IRQ_ENABLE (think host stack will do this) Regards, Richard W. -- 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: MMC_CAP_SDIO_IRQ for omap 3430
On Tue, Oct 20, 2009 at 11:45 AM, John Rigby jcri...@gmail.com wrote: It is still a work in progress because I have hacked the sdio_irq thread to poll all the time. I won't get a chance to do a proper fix for a couple of days at least. The main part of the fix was just turning on the cptl in the same place you turn on the cirq bit. Send me a reminder If you get no offers of testing help from anyone else and I'll try to use my beagle board and wifi card with a modern kernel. I'm happy to test on Overo. Steve John On Mon, Oct 19, 2009 at 10:47 PM, Dirk Behme dirk.be...@googlemail.com wrote: John Rigby wrote: All, Sorry for the delay, I have been without internet access until just now. I added the cptl bit and I don't get continuous cirqs anymore. Right now I have a hacked driver that still does timed polling in sdio_irq.c and also wakes up on cirq. With this config the libertas works well. A flood ping of 1000 packets loses 2. Previously it was dropping about 30% of the packets from a flood ping. Great!! :) Without the polling in sdio_irq.c I get timeouts in libertas driver so I suspect that we may need to add checks of the DAT1 line in other places like the davinci driver does. As I said before, my kernel is a few months old so my issues may not be the same as current head of tree. Do you like to send your changes anyway? Just for reference... Thanks to all who helped on this. Now, the job will be to do this with recent kernel, make it stable and in the mid term get it applied. Anybody likes to help with this? Many thanks and best regards Dirk On Mon, Oct 19, 2009 at 11:24 AM, Madhusudhan madhu...@ti.com wrote: Hi John, So does the SDIO card interrupt mode work fine now? Regards, Madhu -- *From:* John Rigby [mailto:jcri...@gmail.com] *Sent:* Sunday, October 18, 2009 7:24 PM *To:* Woodruff, Richard *Cc:* Dirk Behme; Chikkature Rajashekar, Madhusudhan; linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Steve Sakoman *Subject:* Re: MMC_CAP_SDIO_IRQ for omap 3430 Ok I was going to ask where you found that but I just rechecked the TRM and there it is in plain site: When this bit is set to 1, the host controller automatically disables all the input buffers except the buffer of mmci_dat[1] outside of a transaction in order to detect asynchronous card interrupt on mmci_dat[1] line and minimize the leakage current of the buffers. In my defence, I did search the TRM for every occurance of dat1 but not dat[1]. Oh well live and learn and forget and repeat. John On Sun, Oct 18, 2009 at 6:17 PM, John Rigby jcri...@gmail.com wrote: Richard, MMCHS_CON.CPTL = 1 Don't disable input buffer on DAT1 after completion to allow seeing SDIO interrupt Sounds exactly like what we need. Thanks John On Sun, Oct 18, 2009 at 5:12 PM, Woodruff, Richard r-woodru...@ti.com wrote: From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Dirk Behme Sent: Sunday, October 18, 2009 11:45 AM It would be funny if the TRM was wrong and the CIRQ bit is really cleared by writing 1 to it. I'll try that. A while back I hunted down a few of the bits for this. Maybe this will help some. SYSCONFIG.ENAWAKEUP = 1 allow ocp wrapper to generate an interrupt to prcm MMCHS_HCTL.IWE = 1 route wake up to module ocp wrapper MMCHS_CON.CPTL = 1 Don't disable input buffer on DAT1 after completion to allow seeing SDIO interrupt MMCHS_HCTL.IWE MMCHS_ISE.CIRQ_ENABLE bit to write to enable interrupt at pin MMCHS_STATbit to write for clear of SDIO interrupt R - IRQ_ENABLE (think host stack will do this) Regards, Richard W. -- 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: MMC_CAP_SDIO_IRQ for omap 3430
-Original Message- From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc- ow...@vger.kernel.org] On Behalf Of Dirk Behme Sent: Monday, October 19, 2009 1:17 PM To: linux-omap@vger.kernel.org Cc: Madhusudhan; 'John Rigby'; 'Woodruff, Richard'; linux- m...@vger.kernel.org; 'Steve Sakoman' Subject: Re: MMC_CAP_SDIO_IRQ for omap 3430 Madhusudhan wrote: Hi John, So does the SDIO card interrupt mode work fine now? (wrong attachment in previous mail :( sorry) If somebody likes to test, my updated patch v2 in attachment. Compile tested only, testing and comments are welcome. Can you inline the v2 patch please? It helps review. I wonder in the version that John tested was the CTPL bit set in set_ios or enable_sdio_irq? Regards, Madhu Cheers Dirk _ From: John Rigby [mailto:jcri...@gmail.com] Sent: Sunday, October 18, 2009 7:24 PM To: Woodruff, Richard Cc: Dirk Behme; Chikkature Rajashekar, Madhusudhan; linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Steve Sakoman Subject: Re: MMC_CAP_SDIO_IRQ for omap 3430 Ok I was going to ask where you found that but I just rechecked the TRM and there it is in plain site: When this bit is set to 1, the host controller automatically disables all the input buffers except the buffer of mmci_dat[1] outside of a transaction in order to detect asynchronous card interrupt on mmci_dat[1] line and minimize the leakage current of the buffers. In my defence, I did search the TRM for every occurance of dat1 but not dat[1]. Oh well live and learn and forget and repeat. John On Sun, Oct 18, 2009 at 6:17 PM, John Rigby jcri...@gmail.com wrote: Richard, MMCHS_CON.CPTL = 1 Don't disable input buffer on DAT1 after completion to allow seeing SDIO interrupt Sounds exactly like what we need. Thanks John On Sun, Oct 18, 2009 at 5:12 PM, Woodruff, Richard r-woodru...@ti.com wrote: From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Dirk Behme Sent: Sunday, October 18, 2009 11:45 AM It would be funny if the TRM was wrong and the CIRQ bit is really cleared by writing 1 to it. I'll try that. A while back I hunted down a few of the bits for this. Maybe this will help some. SYSCONFIG.ENAWAKEUP = 1 allow ocp wrapper to generate an interrupt to prcm MMCHS_HCTL.IWE = 1 route wake up to module ocp wrapper MMCHS_CON.CPTL = 1 Don't disable input buffer on DAT1 after completion to allow seeing SDIO interrupt MMCHS_HCTL.IWE MMCHS_ISE.CIRQ_ENABLE bit to write to enable interrupt at pin MMCHS_STATbit to write for clear of SDIO interrupt R - IRQ_ENABLE (think host stack will do this) Regards, Richard W. -- 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: MMC_CAP_SDIO_IRQ for omap 3430
In enable_sdio_irq if enable set ctpl else clear ctpl Again my version is halt baked. I was just happy that enabling ctpl prevents the infinitie cirq issue. On Tue, Oct 20, 2009 at 4:47 PM, Madhusudhan madhu...@ti.com wrote: -Original Message- From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc- ow...@vger.kernel.org] On Behalf Of Dirk Behme Sent: Monday, October 19, 2009 1:17 PM To: linux-omap@vger.kernel.org Cc: Madhusudhan; 'John Rigby'; 'Woodruff, Richard'; linux- m...@vger.kernel.org; 'Steve Sakoman' Subject: Re: MMC_CAP_SDIO_IRQ for omap 3430 Madhusudhan wrote: Hi John, So does the SDIO card interrupt mode work fine now? (wrong attachment in previous mail :( sorry) If somebody likes to test, my updated patch v2 in attachment. Compile tested only, testing and comments are welcome. Can you inline the v2 patch please? It helps review. I wonder in the version that John tested was the CTPL bit set in set_ios or enable_sdio_irq? Regards, Madhu Cheers Dirk _ From: John Rigby [mailto:jcri...@gmail.com] Sent: Sunday, October 18, 2009 7:24 PM To: Woodruff, Richard Cc: Dirk Behme; Chikkature Rajashekar, Madhusudhan; linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Steve Sakoman Subject: Re: MMC_CAP_SDIO_IRQ for omap 3430 Ok I was going to ask where you found that but I just rechecked the TRM and there it is in plain site: When this bit is set to 1, the host controller automatically disables all the input buffers except the buffer of mmci_dat[1] outside of a transaction in order to detect asynchronous card interrupt on mmci_dat[1] line and minimize the leakage current of the buffers. In my defence, I did search the TRM for every occurance of dat1 but not dat[1]. Oh well live and learn and forget and repeat. John On Sun, Oct 18, 2009 at 6:17 PM, John Rigby jcri...@gmail.com wrote: Richard, MMCHS_CON.CPTL = 1 Don't disable input buffer on DAT1 after completion to allow seeing SDIO interrupt Sounds exactly like what we need. Thanks John On Sun, Oct 18, 2009 at 5:12 PM, Woodruff, Richard r-woodru...@ti.com wrote: From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Dirk Behme Sent: Sunday, October 18, 2009 11:45 AM It would be funny if the TRM was wrong and the CIRQ bit is really cleared by writing 1 to it. I'll try that. A while back I hunted down a few of the bits for this. Maybe this will help some. SYSCONFIG.ENAWAKEUP = 1 allow ocp wrapper to generate an interrupt to prcm MMCHS_HCTL.IWE = 1 route wake up to module ocp wrapper MMCHS_CON.CPTL = 1 Don't disable input buffer on DAT1 after completion to allow seeing SDIO interrupt MMCHS_HCTL.IWE MMCHS_ISE.CIRQ_ENABLE bit to write to enable interrupt at pin MMCHS_STATbit to write for clear of SDIO interrupt R - IRQ_ENABLE (think host stack will do this) Regards, Richard W. -- 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: MMC_CAP_SDIO_IRQ for omap 3430
Woodruff, Richard wrote: From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Dirk Behme Sent: Sunday, October 18, 2009 11:45 AM It would be funny if the TRM was wrong and the CIRQ bit is really cleared by writing 1 to it. I'll try that. A while back I hunted down a few of the bits for this. Maybe this will help some. SYSCONFIG.ENAWAKEUP = 1 allow ocp wrapper to generate an interrupt to prcm MMCHS_HCTL.IWE = 1 route wake up to module ocp wrapper MMCHS_CON.CPTL = 1 Don't disable input buffer on DAT1 after completion to allow seeing SDIO interrupt MMCHS_HCTL.IWE MMCHS_ISE.CIRQ_ENABLE bit to write to enable interrupt at pin MMCHS_STATbit to write for clear of SDIO interrupt R - IRQ_ENABLE (think host stack will do this) Thanks! Do you have any idea about MMCHS_HCTL.IBG? This bit is valid only in 4-bit mode of SDIO card to enable interrupt detection in the interrupt cycle at block gap for a multiple block transfer. For MMC cards and for SD card this bit should be set to 0. 0x0: Disable interrupt detection at the block gap in 4-bit mode 0x1: Enable interrupt detection at the block gap in 4-bit mode I saw it neither in the exiting code I looked at, nor in your description above. But it sounds to me that it should be set for 4-bit mode? Best regards Dirk -- 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: MMC_CAP_SDIO_IRQ for omap 3430
From: Dirk Behme [mailto:dirk.be...@googlemail.com] Sent: Monday, October 19, 2009 9:52 AM To: Woodruff, Richard Do you have any idea about MMCHS_HCTL.IBG? Not off the top of my head. I was working with someone who hit issues so I did a quick spec read and came up with previous list. For what its worth when I get a chance I'll take a peek. Regards, Richard W. -- 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: MMC_CAP_SDIO_IRQ for omap 3430
From: John Rigby [mailto:jcri...@gmail.com] Sent: Sunday, October 18, 2009 7:24 PM To: Woodruff, Richard Cc: Dirk Behme; Chikkature Rajashekar, Madhusudhan; linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Steve Sakoman Subject: Re: MMC_CAP_SDIO_IRQ for omap 3430 Ok I was going to ask where you found that but I just rechecked the TRM and there it is in plain site: When this bit is set to 1, the host controller automatically disables all the input buffers except the buffer of mmci_dat[1] outside of a transaction in order to detect asynchronous card interrupt on mmci_dat[1] line and minimize the leakage current of the buffers. In my defence, I did search the TRM for every occurance of dat1 but not dat[1]. Oh well live and learn and forget and repeat. John So, Does the SDIO card interrupt mode work fine now? Regards, Madhu On Sun, Oct 18, 2009 at 6:17 PM, John Rigby jcri...@gmail.com wrote: Richard, MMCHS_CON.CPTL = 1 Don't disable input buffer on DAT1 after completion to allow seeing SDIO interrupt Sounds exactly like what we need. Thanks John On Sun, Oct 18, 2009 at 5:12 PM, Woodruff, Richard r-woodru...@ti.com wrote: From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Dirk Behme Sent: Sunday, October 18, 2009 11:45 AM It would be funny if the TRM was wrong and the CIRQ bit is really cleared by writing 1 to it. I'll try that. A while back I hunted down a few of the bits for this. Maybe this will help some. SYSCONFIG.ENAWAKEUP = 1 allow ocp wrapper to generate an interrupt to prcm MMCHS_HCTL.IWE = 1 route wake up to module ocp wrapper MMCHS_CON.CPTL = 1 Don't disable input buffer on DAT1 after completion to allow seeing SDIO interrupt MMCHS_HCTL.IWE MMCHS_ISE.CIRQ_ENABLE bit to write to enable interrupt at pin MMCHS_STATbit to write for clear of SDIO interrupt R - IRQ_ENABLE (think host stack will do this) Regards, Richard W. -- 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: MMC_CAP_SDIO_IRQ for omap 3430
Madhusudhan wrote: Hi John, So does the SDIO card interrupt mode work fine now? If somebody likes to test, my updated patch v2 in attachment. Compile tested only, testing and comments are welcome. Cheers Dirk _ From: John Rigby [mailto:jcri...@gmail.com] Sent: Sunday, October 18, 2009 7:24 PM To: Woodruff, Richard Cc: Dirk Behme; Chikkature Rajashekar, Madhusudhan; linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Steve Sakoman Subject: Re: MMC_CAP_SDIO_IRQ for omap 3430 Ok I was going to ask where you found that but I just rechecked the TRM and there it is in plain site: When this bit is set to 1, the host controller automatically disables all the input buffers except the buffer of mmci_dat[1] outside of a transaction in order to detect asynchronous card interrupt on mmci_dat[1] line and minimize the leakage current of the buffers. In my defence, I did search the TRM for every occurance of dat1 but not dat[1]. Oh well live and learn and forget and repeat. John On Sun, Oct 18, 2009 at 6:17 PM, John Rigby jcri...@gmail.com wrote: Richard, MMCHS_CON.CPTL = 1 Don't disable input buffer on DAT1 after completion to allow seeing SDIO interrupt Sounds exactly like what we need. Thanks John On Sun, Oct 18, 2009 at 5:12 PM, Woodruff, Richard r-woodru...@ti.com wrote: From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Dirk Behme Sent: Sunday, October 18, 2009 11:45 AM It would be funny if the TRM was wrong and the CIRQ bit is really cleared by writing 1 to it. I'll try that. A while back I hunted down a few of the bits for this. Maybe this will help some. SYSCONFIG.ENAWAKEUP = 1 allow ocp wrapper to generate an interrupt to prcm MMCHS_HCTL.IWE = 1 route wake up to module ocp wrapper MMCHS_CON.CPTL = 1 Don't disable input buffer on DAT1 after completion to allow seeing SDIO interrupt MMCHS_HCTL.IWE MMCHS_ISE.CIRQ_ENABLE bit to write to enable interrupt at pin MMCHS_STATbit to write for clear of SDIO interrupt R - IRQ_ENABLE (think host stack will do this) Regards, Richard W. Subject: [PATCH v2][RFC] OMAP HSMMC: Add SDIO interrupt support Form: Dirk Behme dirk.be...@googlemail.com At the moment, OMAP HSMMC driver supports only SDIO polling, resulting in poor performance. Add support for SDIO interrupt handling. Signed-off-by: Dirk Behme dirk.be...@googlemail.com --- Patch against recent omap-linux head Linux omap got rebuilt from scratch 274c94b29ee7c53609a756acca974e4742c59559 Compile tested only. Please comment and help testing. Changes in v2: - For testing only, hardcode IBG. This should be set only in SDIO and 4-bit mode. But how to detect this? mmc_card_sdio(host-mmc-card) doesn't seem to work here. - Additonally, set CTPL. Is this needed for 1-bit mode? drivers/mmc/host/omap_hsmmc.c | 44 -- 1 file changed, 38 insertions(+), 6 deletions(-) Index: linux-beagle/drivers/mmc/host/omap_hsmmc.c === --- linux-beagle.orig/drivers/mmc/host/omap_hsmmc.c +++ linux-beagle/drivers/mmc/host/omap_hsmmc.c @@ -65,6 +65,7 @@ #define SDVSDET0x0400 #define AUTOIDLE 0x1 #define SDBP (1 8) +#define IBG(1 19) #define DTO0xe #define ICE0x1 #define ICS0x2 @@ -76,6 +77,7 @@ #define INT_EN_MASK0x307F0033 #define BWR_ENABLE (1 4) #define BRR_ENABLE (1 5) +#define CIRQ_ENABLE(1 8) #define INIT_STREAM(1 1) #define DP_SELECT (1 21) #define DDIR (1 4) @@ -84,9 +86,11 @@ #define BCE(1 1) #define FOUR_BIT (1 1) #define DW8(1 5) +#define CTPL (1 11) #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) @@ -268,12 +272,12 @@ static int omap_hsmmc_context_restore(st OMAP_HSMMC_WRITE(host-base, CON, con | DW8); break; case MMC_BUS_WIDTH_4: - OMAP_HSMMC_WRITE(host-base, CON, con ~DW8); + OMAP_HSMMC_WRITE(host-base, CON, (con | CTPL) ~DW8); 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); + OMAP_HSMMC_WRITE(host-base, CON, (con | CTPL) ~DW8); OMAP_HSMMC_WRITE(host-base, HCTL, OMAP_HSMMC_READ(host-base, HCTL) ~FOUR_BIT); break; @@ -653,6 +657,15 @@ static
Re: MMC_CAP_SDIO_IRQ for omap 3430
All, I have sdio working mostly. With a flood ping of 1000 packets I have 2 dropped. Before I was seeing 300+ packets dropped. It is not perfect yet, I am still polling in sdio_irq.c because sometimes the card irq does get dropped. I suspect that is why the davinci driver had extra checks and calls in various places. Also apologies for this redundant reply, the last one was rejected by the vger because of embedded html. John On Mon, Oct 19, 2009 at 11:24 AM, Madhusudhan madhu...@ti.com wrote: Hi John, So does the SDIO card interrupt mode work fine now? Regards, Madhu From: John Rigby [mailto:jcri...@gmail.com] Sent: Sunday, October 18, 2009 7:24 PM To: Woodruff, Richard Cc: Dirk Behme; Chikkature Rajashekar, Madhusudhan; linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Steve Sakoman Subject: Re: MMC_CAP_SDIO_IRQ for omap 3430 Ok I was going to ask where you found that but I just rechecked the TRM and there it is in plain site: When this bit is set to 1, the host controller automatically disables all the input buffers except the buffer of mmci_dat[1] outside of a transaction in order to detect asynchronous card interrupt on mmci_dat[1] line and minimize the leakage current of the buffers. In my defence, I did search the TRM for every occurance of dat1 but not dat[1]. Oh well live and learn and forget and repeat. John On Sun, Oct 18, 2009 at 6:17 PM, John Rigby jcri...@gmail.com wrote: Richard, MMCHS_CON.CPTL = 1 Don't disable input buffer on DAT1 after completion to allow seeing SDIO interrupt Sounds exactly like what we need. Thanks John On Sun, Oct 18, 2009 at 5:12 PM, Woodruff, Richard r-woodru...@ti.com wrote: From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Dirk Behme Sent: Sunday, October 18, 2009 11:45 AM It would be funny if the TRM was wrong and the CIRQ bit is really cleared by writing 1 to it. I'll try that. A while back I hunted down a few of the bits for this. Maybe this will help some. SYSCONFIG.ENAWAKEUP = 1 allow ocp wrapper to generate an interrupt to prcm MMCHS_HCTL.IWE = 1 route wake up to module ocp wrapper MMCHS_CON.CPTL = 1 Don't disable input buffer on DAT1 after completion to allow seeing SDIO interrupt MMCHS_HCTL.IWE MMCHS_ISE.CIRQ_ENABLE bit to write to enable interrupt at pin MMCHS_STATbit to write for clear of SDIO interrupt R - IRQ_ENABLE (think host stack will do this) Regards, Richard W. -- 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: MMC_CAP_SDIO_IRQ for omap 3430
From: John Rigby [mailto:jcri...@gmail.com] Sent: Monday, October 19, 2009 8:13 PM It is not perfect yet, I am still polling in sdio_irq.c because sometimes the card irq does get dropped. I suspect that is why the davinci driver had extra checks and calls in various places. Maybe. Do make sure all power management is shut down during initial testing. The wake up mechanism for INACTIVE and OFF mode likely is not in place properly for MMC. This will make you a bit late for servicing interrupts. It seems unlikely you hit this issue yet, but you will. To wake from OFF mode you will need to set up a GPIO wake from SDIO line. Users I'm aware of so far (ti-wlan chips, etc) have used a separate gpio line for interrupts. Regards, Richard W. -- 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: MMC_CAP_SDIO_IRQ for omap 3430
John Rigby wrote: All, Sorry for the delay, I have been without internet access until just now. I added the cptl bit and I don't get continuous cirqs anymore. Right now I have a hacked driver that still does timed polling in sdio_irq.c and also wakes up on cirq. With this config the libertas works well. A flood ping of 1000 packets loses 2. Previously it was dropping about 30% of the packets from a flood ping. Great!! :) Without the polling in sdio_irq.c I get timeouts in libertas driver so I suspect that we may need to add checks of the DAT1 line in other places like the davinci driver does. As I said before, my kernel is a few months old so my issues may not be the same as current head of tree. Do you like to send your changes anyway? Just for reference... Thanks to all who helped on this. Now, the job will be to do this with recent kernel, make it stable and in the mid term get it applied. Anybody likes to help with this? Many thanks and best regards Dirk On Mon, Oct 19, 2009 at 11:24 AM, Madhusudhan madhu...@ti.com wrote: Hi John, So does the SDIO card interrupt mode work fine now? Regards, Madhu -- *From:* John Rigby [mailto:jcri...@gmail.com] *Sent:* Sunday, October 18, 2009 7:24 PM *To:* Woodruff, Richard *Cc:* Dirk Behme; Chikkature Rajashekar, Madhusudhan; linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Steve Sakoman *Subject:* Re: MMC_CAP_SDIO_IRQ for omap 3430 Ok I was going to ask where you found that but I just rechecked the TRM and there it is in plain site: When this bit is set to 1, the host controller automatically disables all the input buffers except the buffer of mmci_dat[1] outside of a transaction in order to detect asynchronous card interrupt on mmci_dat[1] line and minimize the leakage current of the buffers. In my defence, I did search the TRM for every occurance of dat1 but not dat[1]. Oh well live and learn and forget and repeat. John On Sun, Oct 18, 2009 at 6:17 PM, John Rigby jcri...@gmail.com wrote: Richard, MMCHS_CON.CPTL = 1 Don't disable input buffer on DAT1 after completion to allow seeing SDIO interrupt Sounds exactly like what we need. Thanks John On Sun, Oct 18, 2009 at 5:12 PM, Woodruff, Richard r-woodru...@ti.com wrote: From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Dirk Behme Sent: Sunday, October 18, 2009 11:45 AM It would be funny if the TRM was wrong and the CIRQ bit is really cleared by writing 1 to it. I'll try that. A while back I hunted down a few of the bits for this. Maybe this will help some. SYSCONFIG.ENAWAKEUP = 1 allow ocp wrapper to generate an interrupt to prcm MMCHS_HCTL.IWE = 1 route wake up to module ocp wrapper MMCHS_CON.CPTL = 1 Don't disable input buffer on DAT1 after completion to allow seeing SDIO interrupt MMCHS_HCTL.IWE MMCHS_ISE.CIRQ_ENABLE bit to write to enable interrupt at pin MMCHS_STATbit to write for clear of SDIO interrupt R - IRQ_ENABLE (think host stack will do this) Regards, Richard W. -- 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: MMC_CAP_SDIO_IRQ for omap 3430
Richard, MMCHS_CON.CPTL = 1 Don't disable input buffer on DAT1 after completion to allow seeing SDIO interrupt Sounds exactly like what we need. Thanks John On Sun, Oct 18, 2009 at 5:12 PM, Woodruff, Richard r-woodru...@ti.com wrote: From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Dirk Behme Sent: Sunday, October 18, 2009 11:45 AM It would be funny if the TRM was wrong and the CIRQ bit is really cleared by writing 1 to it. I'll try that. A while back I hunted down a few of the bits for this. Maybe this will help some. SYSCONFIG.ENAWAKEUP = 1 allow ocp wrapper to generate an interrupt to prcm MMCHS_HCTL.IWE = 1 route wake up to module ocp wrapper MMCHS_CON.CPTL = 1 Don't disable input buffer on DAT1 after completion to allow seeing SDIO interrupt MMCHS_HCTL.IWE MMCHS_ISE.CIRQ_ENABLE bit to write to enable interrupt at pin MMCHS_STATbit to write for clear of SDIO interrupt R - IRQ_ENABLE (think host stack will do this) Regards, Richard W. -- 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: MMC_CAP_SDIO_IRQ for omap 3430
John Rigby wrote:
It appears to never get cleared in the status register.
In the OMAP status register, correct? (just to get the correct
understanding)
I added some printks to sdio_irq.c to print the pending interrupts in
the SDIO_CCCR_INTx register for the card and there are no pending
interrupts so I don't think it is a card driver or card issue.
Ok, in other words, this does mean that the card has no interrupt
asserted any more (i.e. it is acknowledged by upper layers, e.g.
libertas driver), but OMAP thinks there is still an interrupt. Right?
This would mean it is an OMAP/omap_hsmmc.c issue. Right?
It would be funny if the TRM was wrong and the CIRQ bit is really
cleared by writing 1 to it. I'll try that.
Have you checked if
- IBG (and 4 bit mode) is correctly set before the first interrupt is
fired (just to make sure that we don't have a function calling order
issue)?
- your HW design has a pull up on DAT1 line (as required by the SD
physical spec)?
Best regards
Dirk
On Fri, Oct 16, 2009 at 3:14 PM, Madhusudhan madhu...@ti.com wrote:
-Original Message-
From: Dirk Behme [mailto:dirk.be...@googlemail.com]
Sent: Friday, October 16, 2009 2:28 PM
To: Madhusudhan Chikkature
Cc: linux-...@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
Re: MMC_CAP_SDIO_IRQ for omap 3430
First, answers to your questions:
The CIRQ bit in the STAT register is on if the CIRQ is enabled in the
IE register and clear when disabled in the IE. That is to say that
the IE register appears to be working.
Yes the card has no pending irqs.
IBG is set really early when the card is discovered. First interrupt
does not occur until much later when the libertas driver asks for
interrupts.
The lines have pull ups.
Now a thought.
Do we need to set DDIR in the CMD reg for CIRQ to work correctly?
Right now it is set at the beginning of data read commands, cleared on
data write commands and otherwise untouched. If DDIR is used
unconditionally to set the direction of the data line buffers then it
would make sense that we need to set the direction to in in order to
monitor the DAT1 line. I will try this Monday when I get back to
work.
John
On Sat, Oct 17, 2009 at 12:30 AM, Dirk Behme dirk.be...@googlemail.com wrote:
John Rigby wrote:
It appears to never get cleared in the status register.
In the OMAP status register, correct? (just to get the correct
understanding)
I added some printks to sdio_irq.c to print the pending interrupts in
the SDIO_CCCR_INTx register for the card and there are no pending
interrupts so I don't think it is a card driver or card issue.
Ok, in other words, this does mean that the card has no interrupt asserted
any more (i.e. it is acknowledged by upper layers, e.g. libertas driver),
but OMAP thinks there is still an interrupt. Right? This would mean it is an
OMAP/omap_hsmmc.c issue. Right?
It would be funny if the TRM was wrong and the CIRQ bit is really
cleared by writing 1 to it. I'll try that.
Have you checked if
- IBG (and 4 bit mode) is correctly set before the first interrupt is fired
(just to make sure that we don't have a function calling order issue)?
- your HW design has a pull up on DAT1 line (as required by the SD physical
spec)?
Best regards
Dirk
On Fri, Oct 16, 2009 at 3:14 PM, Madhusudhan madhu...@ti.com wrote:
-Original Message-
From: Dirk Behme [mailto:dirk.be...@googlemail.com]
Sent: Friday, October 16, 2009 2:28 PM
To: Madhusudhan Chikkature
Cc: linux-...@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
Re: MMC_CAP_SDIO_IRQ for omap 3430
John Rigby wrote:
First, answers to your questions:
The CIRQ bit in the STAT register is on if the CIRQ is enabled in the
IE register and clear when disabled in the IE. That is to say that
the IE register appears to be working.
Yes the card has no pending irqs.
IBG is set really early when the card is discovered. First interrupt
does not occur until much later when the libertas driver asks for
interrupts.
The lines have pull ups.
Ok. This all sounds fine. Thanks for testing/checking all this!
Now a thought.
Do we need to set DDIR in the CMD reg for CIRQ to work correctly?
Right now it is set at the beginning of data read commands, cleared on
data write commands and otherwise untouched. If DDIR is used
unconditionally to set the direction of the data line buffers then it
would make sense that we need to set the direction to in in order to
monitor the DAT1 line. I will try this Monday when I get back to
work.
Sounds like it's time to re-read TRM again.
If somebody has additionally ideas, this would be really helpful!
Madhu: Do you think it would be possible to check inside TI if
somebody has SDIO working on OMAP3 and maybe can provide some example
code?
Many thanks and best regards
Dirk
On Sat, Oct 17, 2009 at 12:30 AM, Dirk Behme dirk.be...@googlemail.com wrote:
John Rigby wrote:
It appears to never get cleared in the status register.
In the OMAP status register, correct? (just to get the correct
understanding)
I added some printks to sdio_irq.c to print the pending interrupts in
the SDIO_CCCR_INTx register for the card and there are no pending
interrupts so I don't think it is a card driver or card issue.
Ok, in other words, this does mean that the card has no interrupt asserted
any more (i.e. it is acknowledged by upper layers, e.g. libertas driver),
but OMAP thinks there is still an interrupt. Right? This would mean it is an
OMAP/omap_hsmmc.c issue. Right?
It would be funny if the TRM was wrong and the CIRQ bit is really
cleared by writing 1 to it. I'll try that.
Have you checked if
- IBG (and 4 bit mode) is correctly set before the first interrupt is fired
(just to make sure that we don't have a function calling order issue)?
- your HW design has a pull up on DAT1 line (as required by the SD physical
spec)?
Best regards
Dirk
On Fri, Oct 16, 2009 at 3:14 PM, Madhusudhan madhu...@ti.com wrote:
-Original Message-
From: Dirk Behme [mailto:dirk.be...@googlemail.com]
Sent: Friday, October 16, 2009 2:28 PM
To: Madhusudhan Chikkature
Cc: linux-...@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
Re: MMC_CAP_SDIO_IRQ for omap 3430
Does anybody have access to omap_hsmmc driver of the SDK 1.0.2
kernel? Or has any hint where to get it from?
https://community.ti.com/forums/p/6290/23867.aspx#23873
talks about
For the SDIO solution, the SDK 1.0.2 kernel supports SDIO out of the
box ...
Thanks
Dirk
John Rigby wrote:
First, answers to your questions:
The CIRQ bit in the STAT register is on if the CIRQ is enabled in the
IE register and clear when disabled in the IE. That is to say that
the IE register appears to be working.
Yes the card has no pending irqs.
IBG is set really early when the card is discovered. First interrupt
does not occur until much later when the libertas driver asks for
interrupts.
The lines have pull ups.
Now a thought.
Do we need to set DDIR in the CMD reg for CIRQ to work correctly?
Right now it is set at the beginning of data read commands, cleared on
data write commands and otherwise untouched. If DDIR is used
unconditionally to set the direction of the data line buffers then it
would make sense that we need to set the direction to in in order to
monitor the DAT1 line. I will try this Monday when I get back to
work.
John
On Sat, Oct 17, 2009 at 12:30 AM, Dirk Behme dirk.be...@googlemail.com wrote:
John Rigby wrote:
It appears to never get cleared in the status register.
In the OMAP status register, correct? (just to get the correct
understanding)
I added some printks to sdio_irq.c to print the pending interrupts in
the SDIO_CCCR_INTx register for the card and there are no pending
interrupts so I don't think it is a card driver or card issue.
Ok, in other words, this does mean that the card has no interrupt asserted
any more (i.e. it is acknowledged by upper layers, e.g. libertas driver),
but OMAP thinks there is still an interrupt. Right? This would mean it is an
OMAP/omap_hsmmc.c issue. Right?
It would be funny if the TRM was wrong and the CIRQ bit is really
cleared by writing 1 to it. I'll try that.
Have you checked if
- IBG (and 4 bit mode) is correctly set before the first interrupt is fired
(just to make sure that we don't have a function calling order issue)?
- your HW design has a pull up on DAT1 line (as required by the SD physical
spec)?
Best regards
Dirk
On Fri, Oct 16, 2009 at 3:14 PM, Madhusudhan madhu...@ti.com wrote:
-Original Message-
From: Dirk Behme [mailto:dirk.be...@googlemail.com]
Sent: Friday, October 16, 2009 2:28 PM
To: Madhusudhan Chikkature
Cc: linux-...@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
Re: MMC_CAP_SDIO_IRQ for omap 3430
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=1bf0587250614c6d8abfe02028b96e0e47148ac8;hb=HEAD
[6] http://www.sdcard.org/developers/tech/sdio/sd_bluetooth_spec/
[7] http://focus.ti.com/lit/ug/spruf98c/spruf98c.pdf
Subject: [PATCH][RFC] OMAP HSMMC: Add SDIO interrupt support
Form: Dirk Behme dirk.be...@googlemail.com
At the moment, OMAP HSMMC driver supports only SDIO polling, resulting in poor
performance. Add support for SDIO interrupt handling.
Signed-off-by: Dirk Behme dirk.be...@googlemail.com
---
Patch against recent omap-linux head Linux omap got rebuilt from scratch
274c94b29ee7c53609a756acca974e4742c59559
Compile tested only. Please comment and help testing.
drivers/mmc/host/omap_hsmmc.c | 48 +-
1 file changed, 43 insertions(+), 5 deletions(-)
Index: linux-beagle/drivers/mmc/host/omap_hsmmc.c
===
--- linux-beagle.orig/drivers/mmc/host/omap_hsmmc.c
+++ linux-beagle/drivers/mmc/host/omap_hsmmc.c
@@ -27,6 +27,7 @@
#include linux/timer.h
#include linux/clk.h
#include linux/mmc/host.h
+#include linux/mmc/card.h
#include linux/mmc/core.h
#include linux/io.h
#include linux/semaphore.h
@@ -65,6 +66,7 @@
#define SDVSDET0x0400
#define AUTOIDLE 0x1
#define SDBP (1 8)
+#define IBG(1 19)
#define DTO0xe
#define ICE0x1
#define ICS0x2
@@ -76,6 +78,7 @@
#define INT_EN_MASK0x307F0033
#define BWR_ENABLE (1 4)
#define BRR_ENABLE (1 5)
+#define CIRQ_ENABLE(1 8)
#define INIT_STREAM(1 1)
#define DP_SELECT (1 21)
#define DDIR (1 4)
@@ -87,6 +90,7 @@
#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)
@@ -653,6 +657,15 @@ static irqreturn_t omap_hsmmc_irq(int ir
status = OMAP_HSMMC_READ(host-base, STAT);
dev_dbg(mmc_dev(host-mmc), IRQ Status is %x\n, status);
+ if (status CIRQ) {
+ dev_dbg(mmc_dev(host-mmc), SDIO interrupt);
+ OMAP_HSMMC_WRITE(host-base, IE, OMAP_HSMMC_READ(host-base, IE)
+ ~(CIRQ_ENABLE));
+ mmc_signal_sdio_irq(host-mmc);
+ spin_unlock(host-irq_lock);
+ return IRQ_HANDLED;
+ }
+
if (status ERR) {
#ifdef CONFIG_MMC_DEBUG
omap_hsmmc_report_irq(host, status);
@@ -1165,8 +1178,15 @@ static void omap_hsmmc_set_ios(struct mm
break;
Re: MMC_CAP_SDIO_IRQ for omap 3430
John, John Rigby wrote: Dirk, Many thanks, after sending the request yesterday I made my own attempt which failed miserably. My patch looks like a subset of yours so that is to be expected. I'll try yours out today and report back my experience. I got already some (private) feedback (thanks!): - Accessing host-mmc-card in omap_hsmmc_set_ios() results in a null pointer :( Seems that mmc-card isn't set yet while calling omap_hsmmc_set_ios(). As workaround, for testing only, I hard coded setting IBG with something like 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); + OMAP_HSMMC_WRITE(host-base, HCTL, +OMAP_HSMMC_READ(host-base, HCTL) | IBG | FOUR_BIT); break; If you test this, be careful that this doesn't hurt any other 4 bit cards except the SDIO you want to test. Later, we have to find a way how to detect that we are in SDIO mode. We want to set IBG only if in SDIO and 4 bit mode. - After this, I got the report that null pointer crash is gone. But SDIO doesn't seem to work any more: libertas_sdio: Libertas SDIO driver libertas_sdio: Copyright Pierre Ossman libertas_sdio mmc1:0001:1: firmware: requesting sd8686_helper.bin libertas_sdio mmc1:0001:1: firmware: requesting sd8686.bin libertas: command 0x0003 timed out libertas: requeueing command 0x0003 due to timeout (#1) libertas: command 0x0003 timed out libertas: requeueing command 0x0003 due to timeout (#2) libertas: command 0x0003 timed out libertas: requeueing command 0x0003 due to timeout (#3) libertas: command 0x0003 timed out libertas: Excessive timeouts submitting command 0x0003 libertas: PREP_CMD: command 0x0003 failed: -110 libertas_sdio: probe of mmc1:0001:1 failed with error -110 I now start to think about it ;) Again, any help would be appreciated! Best regards Dirk On Fri, Oct 16, 2009 at 1:16 AM, Dirk Behme dirk.be...@googlemail.com wrote: 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=1bf0587250614c6d8abfe02028b96e0e47148ac8;hb=HEAD [6] http://www.sdcard.org/developers/tech/sdio/sd_bluetooth_spec/ [7] http://focus.ti.com/lit/ug/spruf98c/spruf98c.pdf Subject: [PATCH][RFC] OMAP HSMMC: Add SDIO interrupt support Form: Dirk Behme dirk.be...@googlemail.com At the moment, OMAP HSMMC driver supports only SDIO polling, resulting in poor performance. Add support for SDIO interrupt handling. Signed-off-by: Dirk Behme dirk.be...@googlemail.com --- Patch against recent omap-linux head Linux omap got rebuilt from scratch 274c94b29ee7c53609a756acca974e4742c59559 Compile tested only. Please comment and help testing. drivers/mmc/host/omap_hsmmc.c | 48
Re: MMC_CAP_SDIO_IRQ for omap 3430
Dirk, Thanks for the update. After looking more closely at your patch I found that the only thing my attempt was missing was the IBG setting. I added that to mine with the result that the system hangs on loading the libertas modules. The last thing i see is the firmware request message. I will continue to work on this and let you know what I find. John On Fri, Oct 16, 2009 at 9:02 AM, Dirk Behme dirk.be...@googlemail.com wrote: John, John Rigby wrote: Dirk, Many thanks, after sending the request yesterday I made my own attempt which failed miserably. My patch looks like a subset of yours so that is to be expected. I'll try yours out today and report back my experience. I got already some (private) feedback (thanks!): - Accessing host-mmc-card in omap_hsmmc_set_ios() results in a null pointer :( Seems that mmc-card isn't set yet while calling omap_hsmmc_set_ios(). As workaround, for testing only, I hard coded setting IBG with something like 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); + OMAP_HSMMC_WRITE(host-base, HCTL, + OMAP_HSMMC_READ(host-base, HCTL) | IBG | FOUR_BIT); break; If you test this, be careful that this doesn't hurt any other 4 bit cards except the SDIO you want to test. Later, we have to find a way how to detect that we are in SDIO mode. We want to set IBG only if in SDIO and 4 bit mode. - After this, I got the report that null pointer crash is gone. But SDIO doesn't seem to work any more: libertas_sdio: Libertas SDIO driver libertas_sdio: Copyright Pierre Ossman libertas_sdio mmc1:0001:1: firmware: requesting sd8686_helper.bin libertas_sdio mmc1:0001:1: firmware: requesting sd8686.bin libertas: command 0x0003 timed out libertas: requeueing command 0x0003 due to timeout (#1) libertas: command 0x0003 timed out libertas: requeueing command 0x0003 due to timeout (#2) libertas: command 0x0003 timed out libertas: requeueing command 0x0003 due to timeout (#3) libertas: command 0x0003 timed out libertas: Excessive timeouts submitting command 0x0003 libertas: PREP_CMD: command 0x0003 failed: -110 libertas_sdio: probe of mmc1:0001:1 failed with error -110 I now start to think about it ;) Again, any help would be appreciated! Best regards Dirk On Fri, Oct 16, 2009 at 1:16 AM, Dirk Behme dirk.be...@googlemail.com wrote: 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=1bf0587250614c6d8abfe02028b96e0e47148ac8;hb=HEAD [6] http://www.sdcard.org/developers/tech/sdio/sd_bluetooth_spec/ [7] http://focus.ti.com/lit/ug/spruf98c/spruf98c.pdf Subject:
Re: MMC_CAP_SDIO_IRQ for omap 3430
John Rigby wrote:
Dirk,
Thanks for the update. After looking more closely at your patch I
found that the only thing my attempt was missing was the IBG setting.
I added that to mine with the result that the system hangs on loading
the libertas modules.
On which board are you working? libertas does mean you are working on
wifi connected via SDIO?
The last thing i see is the firmware request
message.
Ok, you see a hang. Below we have a timeout.
I would vote for some interrupt issues. For timeouts I would vote for
missing interrupts, while system hang might be infinite interrupts
(something like this was reported in [1]).
Could you add some debug code in omap_hsmmc_enable_sdio_irq() to trace
if enable/disable is called in the correct order? And in
omap_hsmmc_irq() in if (status CIRQ) { to check if and how often it
is called?
Best regards
Dirk
[1] http://groups.google.com/group/beagleboard/msg/5cdfe2a319531937
On Fri, Oct 16, 2009 at 9:02 AM, Dirk Behme dirk.be...@googlemail.com wrote:
John,
John Rigby wrote:
Dirk,
Many thanks, after sending the request yesterday I made my own attempt
which failed miserably. My patch looks like a subset of yours so that
is to be expected. I'll try yours out today and report back my
experience.
I got already some (private) feedback (thanks!):
- Accessing host-mmc-card in omap_hsmmc_set_ios() results in a null
pointer :( Seems that mmc-card isn't set yet while calling
omap_hsmmc_set_ios().
As workaround, for testing only, I hard coded setting IBG with something
like
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);
+ OMAP_HSMMC_WRITE(host-base, HCTL,
+OMAP_HSMMC_READ(host-base, HCTL) |
IBG | FOUR_BIT);
break;
If you test this, be careful that this doesn't hurt any other 4 bit cards
except the SDIO you want to test.
Later, we have to find a way how to detect that we are in SDIO mode. We want
to set IBG only if in SDIO and 4 bit mode.
- After this, I got the report that null pointer crash is gone. But SDIO
doesn't seem to work any more:
libertas_sdio: Libertas SDIO driver
libertas_sdio: Copyright Pierre Ossman
libertas_sdio mmc1:0001:1: firmware: requesting sd8686_helper.bin
libertas_sdio mmc1:0001:1: firmware: requesting sd8686.bin
libertas: command 0x0003 timed out
libertas: requeueing command 0x0003 due to timeout (#1)
libertas: command 0x0003 timed out
libertas: requeueing command 0x0003 due to timeout (#2)
libertas: command 0x0003 timed out
libertas: requeueing command 0x0003 due to timeout (#3)
libertas: command 0x0003 timed out
libertas: Excessive timeouts submitting command 0x0003
libertas: PREP_CMD: command 0x0003 failed: -110
libertas_sdio: probe of mmc1:0001:1 failed with error -110
I now start to think about it ;)
Again, any help would be appreciated!
Best regards
Dirk
On Fri, Oct 16, 2009 at 1:16 AM, Dirk Behme dirk.be...@googlemail.com
wrote:
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]
Re: MMC_CAP_SDIO_IRQ for omap 3430
Hi Dirk,
I am inlining the patch so that it helps review.
Subject: [PATCH][RFC] OMAP HSMMC: Add SDIO interrupt support
Form: Dirk Behme dirk.be...@googlemail.com
At the moment, OMAP HSMMC driver supports only SDIO polling, resulting in poor
performance. Add support for SDIO interrupt handling.
Signed-off-by: Dirk Behme dirk.be...@googlemail.com
---
Patch against recent omap-linux head Linux omap got rebuilt from scratch
274c94b29ee7c53609a756acca974e4742c59559
Compile tested only. Please comment and help testing.
drivers/mmc/host/omap_hsmmc.c | 48 +-
1 file changed, 43 insertions(+), 5 deletions(-)
Index: linux-beagle/drivers/mmc/host/omap_hsmmc.c
===
--- linux-beagle.orig/drivers/mmc/host/omap_hsmmc.c
+++ linux-beagle/drivers/mmc/host/omap_hsmmc.c
@@ -27,6 +27,7 @@
#include linux/timer.h
#include linux/clk.h
#include linux/mmc/host.h
+#include linux/mmc/card.h
#include linux/mmc/core.h
#include linux/io.h
#include linux/semaphore.h
@@ -65,6 +66,7 @@
#define SDVSDET0x0400
#define AUTOIDLE 0x1
#define SDBP (1 8)
+#define IBG(1 19)
#define DTO0xe
#define ICE0x1
#define ICS0x2
@@ -76,6 +78,7 @@
#define INT_EN_MASK0x307F0033
#define BWR_ENABLE (1 4)
#define BRR_ENABLE (1 5)
+#define CIRQ_ENABLE(1 8)
#define INIT_STREAM(1 1)
#define DP_SELECT (1 21)
#define DDIR (1 4)
@@ -87,6 +90,7 @@
#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)
@@ -653,6 +657,15 @@ static irqreturn_t omap_hsmmc_irq(int ir
status = OMAP_HSMMC_READ(host-base, STAT);
dev_dbg(mmc_dev(host-mmc), IRQ Status is %x\n, status);
+ if (status CIRQ) {
+ dev_dbg(mmc_dev(host-mmc), SDIO interrupt);
+ OMAP_HSMMC_WRITE(host-base, IE, OMAP_HSMMC_READ(host-base, IE)
+ ~(CIRQ_ENABLE));
+ mmc_signal_sdio_irq(host-mmc);
+ spin_unlock(host-irq_lock);
+ return IRQ_HANDLED;
+ }
+
if (status ERR) {
#ifdef CONFIG_MMC_DEBUG
omap_hsmmc_report_irq(host, status);
@@ -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. But the
dependancy on 4-bit seems to be a problem here.
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.
+ 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 @@
Re: MMC_CAP_SDIO_IRQ for omap 3430
First the disclaimers:
The board is new board that has had hardware mmc/sdio problems before.
It is based closely on beagle but uses a different package which has
some package specific issues. We think we have found them all but who
knows.
My kernel is a few months old 2.6.29.
Ok, given the above issues, it looks to me like I am getting
interrupted every time CIRQ is enabled. Nor sure if the libertas
driver is not disabling as it should or what. So I end up in this
death spiral:
irq handler is called and status indicates CIRQ is pending
mmc_signal_sdio_irq is called which calls omap_hsmmc_enable_sdio_irq
with via mmc_host_ops, en is zero so CIRQ gets disabled
mmc_signal_sdio_irq then wakes up sdio_irq_thread which does its thing
then before going to sleep calls omap_hsmmc_enable_irq with en set to
1 so CIRC gets turned back on
with CIRC enabled the irq handler gets called and we are back where we started.
Looks like either the libertas driver is not disabling the irq or the
CIRQ irq is somehow getting stuck or I have a hw problem.
One thing I did try was to have the sdio_irq_thread basically ignore
the MMC_CAP_SDIO_IRQ flag except for calling
host-ops-enable_sdio_irq(host, 1) and I changed mmc_signal_sdio_irq
to not reschedule sdio_irq_thread. In shows that the mere act of
enabling CIRQ does not break anything. In this mode I get one CIRQ
irq for each time around the sdio_irq_thread loop.
I guess I should try checking the CIRQ bit in the status register
after calling the libertas handler which should clear the irq?
John
On Fri, Oct 16, 2009 at 10:06 AM, Dirk Behme dirk.be...@googlemail.com wrote:
John Rigby wrote:
Dirk,
Thanks for the update. After looking more closely at your patch I
found that the only thing my attempt was missing was the IBG setting.
I added that to mine with the result that the system hangs on loading
the libertas modules.
On which board are you working? libertas does mean you are working on wifi
connected via SDIO?
The last thing i see is the firmware request
message.
Ok, you see a hang. Below we have a timeout.
I would vote for some interrupt issues. For timeouts I would vote for
missing interrupts, while system hang might be infinite interrupts
(something like this was reported in [1]).
Could you add some debug code in omap_hsmmc_enable_sdio_irq() to trace if
enable/disable is called in the correct order? And in omap_hsmmc_irq() in if
(status CIRQ) { to check if and how often it is called?
Best regards
Dirk
[1] http://groups.google.com/group/beagleboard/msg/5cdfe2a319531937
On Fri, Oct 16, 2009 at 9:02 AM, Dirk Behme dirk.be...@googlemail.com
wrote:
John,
John Rigby wrote:
Dirk,
Many thanks, after sending the request yesterday I made my own attempt
which failed miserably. My patch looks like a subset of yours so that
is to be expected. I'll try yours out today and report back my
experience.
I got already some (private) feedback (thanks!):
- Accessing host-mmc-card in omap_hsmmc_set_ios() results in a null
pointer :( Seems that mmc-card isn't set yet while calling
omap_hsmmc_set_ios().
As workaround, for testing only, I hard coded setting IBG with something
like
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);
+ OMAP_HSMMC_WRITE(host-base, HCTL,
+ OMAP_HSMMC_READ(host-base,
HCTL) |
IBG | FOUR_BIT);
break;
If you test this, be careful that this doesn't hurt any other 4 bit cards
except the SDIO you want to test.
Later, we have to find a way how to detect that we are in SDIO mode. We
want
to set IBG only if in SDIO and 4 bit mode.
- After this, I got the report that null pointer crash is gone. But SDIO
doesn't seem to work any more:
libertas_sdio: Libertas SDIO driver
libertas_sdio: Copyright Pierre Ossman
libertas_sdio mmc1:0001:1: firmware: requesting sd8686_helper.bin
libertas_sdio mmc1:0001:1: firmware: requesting sd8686.bin
libertas: command 0x0003 timed out
libertas: requeueing command 0x0003 due to timeout (#1)
libertas: command 0x0003 timed out
libertas: requeueing command 0x0003 due to timeout (#2)
libertas: command 0x0003 timed out
libertas: requeueing command 0x0003 due to timeout (#3)
libertas: command 0x0003 timed out
libertas: Excessive timeouts submitting command 0x0003
libertas: PREP_CMD: command 0x0003 failed: -110
libertas_sdio: probe of mmc1:0001:1 failed with error -110
I now start to think about it ;)
Again, any help would be appreciated!
Best regards
Dirk
On Fri, Oct 16, 2009 at 1:16 AM, Dirk Behme dirk.be...@googlemail.com
wrote:
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
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?
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
Re: MMC_CAP_SDIO_IRQ for omap 3430
John Rigby wrote:
First the disclaimers:
The board is new board that has had hardware mmc/sdio problems before.
It is based closely on beagle but uses a different package which has
some package specific issues. We think we have found them all but who
knows.
My kernel is a few months old 2.6.29.
Then you can't apply my patch 1:1. Steve already found that there are
a lot of differences between recent git head and 2.6.31. A lot of
omap_hsmmc changes were done since 2.6.31.
Ok, given the above issues, it looks to me like I am getting
interrupted every time CIRQ is enabled.
Infinite interrupts. This is what I assumed :(
Nor sure if the libertas
driver is not disabling as it should or what.
I'm not sure if libertas has to do something with this.
So I end up in this
death spiral:
irq handler is called and status indicates CIRQ is pending
mmc_signal_sdio_irq is called which calls omap_hsmmc_enable_sdio_irq
with via mmc_host_ops, en is zero so CIRQ gets disabled
mmc_signal_sdio_irq then wakes up sdio_irq_thread which does its thing
then before going to sleep calls omap_hsmmc_enable_irq with en set to
1 so CIRC gets turned back on
Sounds ok. And thanks for giving the call stack. As mentioned, I did
only compile check ;)
with CIRC enabled the irq handler gets called and we are back where we started.
The issue then is not acknowledging the interrupt correctly. The TRM
(spruf98.c) tells us:
-- cut --
Card interrupt Enable
A clear of this bit also clears the corresponding status bit.
During 1-bit mode, if the interrupt routine does not remove the
source of a card interrupt in the SDIO card, the status bit is
reasserted when this bit is set to 1.
-- cut --
The clear card interrupt enable should be done by ~(CIRQ_ENABLE) in
+if (status CIRQ) {
+ dev_dbg(mmc_dev(host-mmc), SDIO interrupt);
+ OMAP_HSMMC_WRITE(host-base, IE, OMAP_HSMMC_READ(host-base, IE)
+ ~(CIRQ_ENABLE));
+ mmc_signal_sdio_irq(host-mmc);
+ spin_unlock(host-irq_lock);
+ return IRQ_HANDLED;
+}
Anybody sees anything wrong here? Maybe we missed something?
I assume that we are not in 1-bit mode. We should be in 4 bit mode. It
could be checked by some test code that we are in 4 bit mode and IBG
is set.
Additionally, what I wonder regarding this, is the davinci driver [1]
additionally checking for DAT1 level in enable_sdio_irq
1114 if (enable) {
1115 if (!((readl(host-base + DAVINCI_SDIOST0))
1116 SDIOST0_DAT1_HI)) {
1117 writel(SDIOIST_IOINT,
1118 host-base +
DAVINCI_SDIOIST);
1119 mmc_signal_sdio_irq(host-mmc);
1120 } else {
... enable int
1124 }
1125 } else {
... disable int
1129 }
And it does similar stuff in xfer_done
873 if (host-mmc-caps MMC_CAP_SDIO_IRQ) {
874 if (host-sdio_int (!((readl(host-base +
DAVINCI_SDIOST0))
875 SDIOST0_DAT1_HI))) {
876 writel(SDIOIST_IOINT, host-base +
DAVINCI_SDIOIST);
877 mmc_signal_sdio_irq(host-mmc);
878 }
879 }
Most probably there is a reason for doing so?
Best regards
Dirk
[1]
http://arago-project.org/git/projects/?p=linux-davinci.git;a=blob;f=drivers/mmc/host/davinci_mmc.c;h=1bf0587250614c6d8abfe02028b96e0e47148ac8;hb=HEAD
Looks like either the libertas driver is not disabling the irq or the
CIRQ irq is somehow getting stuck or I have a hw problem.
One thing I did try was to have the sdio_irq_thread basically ignore
the MMC_CAP_SDIO_IRQ flag except for calling
host-ops-enable_sdio_irq(host, 1) and I changed mmc_signal_sdio_irq
to not reschedule sdio_irq_thread. In shows that the mere act of
enabling CIRQ does not break anything. In this mode I get one CIRQ
irq for each time around the sdio_irq_thread loop.
I guess I should try checking the CIRQ bit in the status register
after calling the libertas handler which should clear the irq?
John
On Fri, Oct 16, 2009 at 10:06 AM, Dirk Behme dirk.be...@googlemail.com wrote:
John Rigby wrote:
Dirk,
Thanks for the update. After looking more closely at your patch I
found that the only thing my attempt was missing was the IBG setting.
I added that to mine with the result that the system hangs on loading
the libertas modules.
On which board are you working? libertas does mean you are working on wifi
connected via SDIO?
The last thing i see is the firmware request
message.
Ok, you see a hang. Below we have a timeout.
I would vote for some interrupt issues. For timeouts I would vote for
missing interrupts, while system hang might be infinite interrupts
(something like this was reported in [1]).
Could you add some debug code in omap_hsmmc_enable_sdio_irq() to trace if
enable/disable is called in the correct order? And in
Re: MMC_CAP_SDIO_IRQ for omap 3430
cc'ing list after responding only to Dirk.
On Fri, Oct 16, 2009 at 2:37 PM, John Rigby jcri...@gmail.com wrote:
On Fri, Oct 16, 2009 at 1:55 PM, Dirk Behme dirk.be...@googlemail.com wrote:
John Rigby wrote:
First the disclaimers:
The board is new board that has had hardware mmc/sdio problems before.
It is based closely on beagle but uses a different package which has
some package specific issues. We think we have found them all but who
knows.
My kernel is a few months old 2.6.29.
Then you can't apply my patch 1:1. Steve already found that there are a lot
of differences between recent git head and 2.6.31. A lot of omap_hsmmc
changes were done since 2.6.31.
I applied your patch in spirit:) thus the disclaimer.
.
Additionally, what I wonder regarding this, is the davinci driver [1]
additionally checking for DAT1 level in enable_sdio_irq
1114 if (enable) {
1115 if (!((readl(host-base + DAVINCI_SDIOST0))
1116 SDIOST0_DAT1_HI)) {
1117 writel(SDIOIST_IOINT,
1118 host-base + DAVINCI_SDIOIST);
1119 mmc_signal_sdio_irq(host-mmc);
1120 } else {
... enable int
1124 }
1125 } else {
... disable int
1129 }
And it does similar stuff in xfer_done
873 if (host-mmc-caps MMC_CAP_SDIO_IRQ) {
874 if (host-sdio_int (!((readl(host-base +
DAVINCI_SDIOST0))
875 SDIOST0_DAT1_HI))) {
876 writel(SDIOIST_IOINT, host-base +
DAVINCI_SDIOIST);
877 mmc_signal_sdio_irq(host-mmc);
878 }
879 }
Most probably there is a reason for doing so?
This looks to me like it is detecting the irq where the hw may not
otherwise do so. It is basically saying if the line is low signal an
sdio irq. Sort of the opposite of the problem we have.
--
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: MMC_CAP_SDIO_IRQ for omap 3430
-Original Message-
From: Dirk Behme [mailto:dirk.be...@googlemail.com]
Sent: Friday, October 16, 2009 2:28 PM
To: Madhusudhan Chikkature
Cc: linux-...@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
Re: MMC_CAP_SDIO_IRQ for omap 3430
It appears to never get cleared in the status register.
I added some printks to sdio_irq.c to print the pending interrupts in
the SDIO_CCCR_INTx register for the card and there are no pending
interrupts so I don't think it is a card driver or card issue.
It would be funny if the TRM was wrong and the CIRQ bit is really
cleared by writing 1 to it. I'll try that.
John
On Fri, Oct 16, 2009 at 3:14 PM, Madhusudhan madhu...@ti.com wrote:
-Original Message-
From: Dirk Behme [mailto:dirk.be...@googlemail.com]
Sent: Friday, October 16, 2009 2:28 PM
To: Madhusudhan Chikkature
Cc: linux-...@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
