diff mbox

[V2,10/15] mmc: sdhci-esdhc-imx: enable hw auto retuning for MAN_TUNING

Message ID 1468309584-3591-11-git-send-email-aisheng.dong@nxp.com (mailing list archive)
State New, archived
Headers show

Commit Message

Dong Aisheng July 12, 2016, 7:46 a.m. UTC 
Indicating hw auto retuning support for mx6qdl in the fake caps_1
register and enable auto retuning in post_tuning process after
tuning completes.

Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
---
 drivers/mmc/host/sdhci-esdhc-imx.c | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

Comments

Gary Bisson Aug. 15, 2016, 2:59 p.m. UTC | #1 
Dong Aisheng, All,

On Tue, Jul 12, 2016 at 03:46:19PM +0800, Dong Aisheng wrote:
> Indicating hw auto retuning support for mx6qdl in the fake caps_1
> register and enable auto retuning in post_tuning process after
> tuning completes.

Have you tried this change with a SDIO3.0 device? I'm asking because a
similar change in latest NXP 4.1.15 kernel broke SDIO3.0 support.
With this tuning, the kernel would report:
mmc2: Got data interrupt 0x00000002 even though no data operation was in
progress.

Doing a 'git bisect' and then reverting this patch fixed the issue.
Although I haven't tested that change on mainline kernel, I wanted you
to know about this observation before it gets merged.

As a FYI, the issue has been reported to NXP community:
https://community.nxp.com/thread/431316

Regards,
Gary
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Dong Aisheng Aug. 16, 2016, 10:18 a.m. UTC | #2 
On Mon, Aug 15, 2016 at 04:59:41PM +0200, Gary Bisson wrote:
> Dong Aisheng, All,
> 
> On Tue, Jul 12, 2016 at 03:46:19PM +0800, Dong Aisheng wrote:
> > Indicating hw auto retuning support for mx6qdl in the fake caps_1
> > register and enable auto retuning in post_tuning process after
> > tuning completes.
> 
> Have you tried this change with a SDIO3.0 device? I'm asking because a

Tested with SD3.0 device.
Not really for SDIO3.0 device since there's no SDIO3.0 device on my
available MX6Q/DL boards.

> similar change in latest NXP 4.1.15 kernel broke SDIO3.0 support.
> With this tuning, the kernel would report:
> mmc2: Got data interrupt 0x00000002 even though no data operation was in
> progress.
> 

Can you provide the full enumeration log?

> Doing a 'git bisect' and then reverting this patch fixed the issue.
> Although I haven't tested that change on mainline kernel, I wanted you
> to know about this observation before it gets merged.
> 
> As a FYI, the issue has been reported to NXP community:
> https://community.nxp.com/thread/431316
> 

Thanks for nofity.
I will check it on my side.

Regards
Dong Aisheng

> Regards,
> Gary
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Gary Bisson Aug. 16, 2016, 12:44 p.m. UTC | #3 
On Tue, Aug 16, 2016 at 06:18:18PM +0800, Dong Aisheng wrote:
> On Mon, Aug 15, 2016 at 04:59:41PM +0200, Gary Bisson wrote:
> > Dong Aisheng, All,
> > 
> > On Tue, Jul 12, 2016 at 03:46:19PM +0800, Dong Aisheng wrote:
> > > Indicating hw auto retuning support for mx6qdl in the fake caps_1
> > > register and enable auto retuning in post_tuning process after
> > > tuning completes.
> > 
> > Have you tried this change with a SDIO3.0 device? I'm asking because a
> 
> Tested with SD3.0 device.
> Not really for SDIO3.0 device since there's no SDIO3.0 device on my
> available MX6Q/DL boards.

Someone answered on the Community that it has been tested on i.MX7 SABRE
board but not on i.MX6 right?

> > similar change in latest NXP 4.1.15 kernel broke SDIO3.0 support.
> > With this tuning, the kernel would report:
> > mmc2: Got data interrupt 0x00000002 even though no data operation was in
> > progress.
> > 
> 
> Can you provide the full enumeration log?

Here is the mmc related part of dmesg:
# dmesg | grep mmc2
mmc2: SDHCI controller on 2194000.usdhc [2194000.usdhc] using ADMA
mmc2: queuing unknown CIS tuple 0x01 (3 bytes)
mmc2: queuing unknown CIS tuple 0x1a (5 bytes)
mmc2: queuing unknown CIS tuple 0x1b (8 bytes)
mmc2: queuing unknown CIS tuple 0x14 (0 bytes)
mmc2: queuing unknown CIS tuple 0x80 (1 bytes)
mmc2: queuing unknown CIS tuple 0x81 (1 bytes)
mmc2: queuing unknown CIS tuple 0x82 (1 bytes)
mmc2: new ultra high speed SDR104 SDIO card at address 0001
mmc2: queuing unknown CIS tuple 0x01 (3 bytes)
mmc2: queuing unknown CIS tuple 0x1a (5 bytes)
mmc2: queuing unknown CIS tuple 0x1b (8 bytes)
mmc2: queuing unknown CIS tuple 0x14 (0 bytes)
ar6k_wlan mmc2:0001:1: Direct firmware load for qsetup30.bin failed with
error -2
mmc2: Got data interrupt 0x00000002 even though no data operation was in
progress.
mmc2: Got data interrupt 0x00000002 even though no data operation was in
progress.

Without the MAN_TUN patch, everything is the same (as expected) but
without the last two errors. Note that when WiFi connection is up, this
warning keeps poping up every few seconds.

> > Doing a 'git bisect' and then reverting this patch fixed the issue.
> > Although I haven't tested that change on mainline kernel, I wanted you
> > to know about this observation before it gets merged.
> > 
> > As a FYI, the issue has been reported to NXP community:
> > https://community.nxp.com/thread/431316
> > 
> 
> Thanks for nofity.
> I will check it on my side.

Not sure you've seen my last post from today, but you can actually try
the device I'm using (QCA9377) on SABRE using the evaluation kit:
http://www.silexamerica.com/products/connectivity-solutions/embedded-wireless/sdio-radios/sx-sdcac/

Maybe there's a hw mod to do on SABRE in order to get SDIO3.0/1.8V vcc.

Regards,
Gary
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Dong Aisheng Aug. 17, 2016, 2:31 p.m. UTC | #4 
Hi Gary,

On Tue, Aug 16, 2016 at 8:44 PM, Gary Bisson
<gary.bisson@boundarydevices.com> wrote:
> On Tue, Aug 16, 2016 at 06:18:18PM +0800, Dong Aisheng wrote:
>> On Mon, Aug 15, 2016 at 04:59:41PM +0200, Gary Bisson wrote:
>> > Dong Aisheng, All,
>> >
>> > On Tue, Jul 12, 2016 at 03:46:19PM +0800, Dong Aisheng wrote:
>> > > Indicating hw auto retuning support for mx6qdl in the fake caps_1
>> > > register and enable auto retuning in post_tuning process after
>> > > tuning completes.
>> >
>> > Have you tried this change with a SDIO3.0 device? I'm asking because a
>>
>> Tested with SD3.0 device.
>> Not really for SDIO3.0 device since there's no SDIO3.0 device on my
>> available MX6Q/DL boards.
>
> Someone answered on the Community that it has been tested on i.MX7 SABRE
> board but not on i.MX6 right?
>

Yes, we tested this feature with MX7 SDB board.
However, MX7 is slightly a bit different from MX6 that it's using STD_TUNING
rather than MAN_TUNING.

I just tried MAN_TUNING on MX7 which is the same as MX6, but i still
couldn't see your issue.

May try more and also on MX6 boards.

>> > similar change in latest NXP 4.1.15 kernel broke SDIO3.0 support.
>> > With this tuning, the kernel would report:
>> > mmc2: Got data interrupt 0x00000002 even though no data operation was in
>> > progress.
>> >
>>
>> Can you provide the full enumeration log?
>
> Here is the mmc related part of dmesg:
> # dmesg | grep mmc2
> mmc2: SDHCI controller on 2194000.usdhc [2194000.usdhc] using ADMA
> mmc2: queuing unknown CIS tuple 0x01 (3 bytes)
> mmc2: queuing unknown CIS tuple 0x1a (5 bytes)
> mmc2: queuing unknown CIS tuple 0x1b (8 bytes)
> mmc2: queuing unknown CIS tuple 0x14 (0 bytes)
> mmc2: queuing unknown CIS tuple 0x80 (1 bytes)
> mmc2: queuing unknown CIS tuple 0x81 (1 bytes)
> mmc2: queuing unknown CIS tuple 0x82 (1 bytes)
> mmc2: new ultra high speed SDR104 SDIO card at address 0001
> mmc2: queuing unknown CIS tuple 0x01 (3 bytes)
> mmc2: queuing unknown CIS tuple 0x1a (5 bytes)
> mmc2: queuing unknown CIS tuple 0x1b (8 bytes)
> mmc2: queuing unknown CIS tuple 0x14 (0 bytes)
> ar6k_wlan mmc2:0001:1: Direct firmware load for qsetup30.bin failed with
> error -2
> mmc2: Got data interrupt 0x00000002 even though no data operation was in
> progress.
> mmc2: Got data interrupt 0x00000002 even though no data operation was in
> progress.
>
> Without the MAN_TUN patch, everything is the same (as expected) but
> without the last two errors. Note that when WiFi connection is up, this
> warning keeps poping up every few seconds.
>

Could you please enable CONFIG_MMC_DEBUG and send out the full
card enumeration log?

>> > Doing a 'git bisect' and then reverting this patch fixed the issue.
>> > Although I haven't tested that change on mainline kernel, I wanted you
>> > to know about this observation before it gets merged.
>> >
>> > As a FYI, the issue has been reported to NXP community:
>> > https://community.nxp.com/thread/431316
>> >
>>
>> Thanks for nofity.
>> I will check it on my side.
>
> Not sure you've seen my last post from today, but you can actually try
> the device I'm using (QCA9377) on SABRE using the evaluation kit:
> http://www.silexamerica.com/products/connectivity-solutions/embedded-wireless/sdio-radios/sx-sdcac/
>

I do not have that WiFi card.
But i have a Broadcom SDIO3.0 WiFi card, i will find way to run it on MX6 board.

> Maybe there's a hw mod to do on SABRE in order to get SDIO3.0/1.8V vcc.
>

Did your card work on 1.8v IO voltage?
AFAIK usually the SDIO3.0 external WiFi card may not support 1.8v VIO and
needs special HW rework.

> Regards,
> Gary

Regards
Dong Aisheng
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c b/drivers/mmc/host/sdhci-esdhc-imx.c
index c90aa07b106f..ac2c83af7440 100644
--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -302,7 +302,8 @@  static u32 esdhc_readl_le(struct sdhci_host *host, int reg)
 				/* imx6q/dl does not have cap_1 register, fake one */
 				val = SDHCI_SUPPORT_DDR50 | SDHCI_SUPPORT_SDR104
 					| SDHCI_SUPPORT_SDR50
-					| SDHCI_USE_SDR50_TUNING;
+					| SDHCI_USE_SDR50_TUNING
+					| (SDHCI_TUNING_MODE_3 << SDHCI_RETUNING_MODE_SHIFT);
 
 			if (imx_data->socdata->flags & ESDHC_FLAG_HS400)
 				val |= SDHCI_SUPPORT_HS400;
@@ -472,10 +473,13 @@  static void esdhc_writew_le(struct sdhci_host *host, u16 val, int reg)
 		writel(new_val, host->ioaddr + ESDHC_VENDOR_SPEC);
 		if (imx_data->socdata->flags & ESDHC_FLAG_MAN_TUNING) {
 			new_val = readl(host->ioaddr + ESDHC_MIX_CTRL);
-			if (val & SDHCI_CTRL_TUNED_CLK)
+			if (val & SDHCI_CTRL_TUNED_CLK) {
 				new_val |= ESDHC_MIX_CTRL_SMPCLK_SEL;
-			else
+				new_val |= ESDHC_MIX_CTRL_AUTO_TUNE_EN;
+			} else {
 				new_val &= ~ESDHC_MIX_CTRL_SMPCLK_SEL;
+				new_val &= ~ESDHC_MIX_CTRL_AUTO_TUNE_EN;
+			}
 			writel(new_val , host->ioaddr + ESDHC_MIX_CTRL);
 		} else if (imx_data->socdata->flags & ESDHC_FLAG_STD_TUNING) {
 			u32 v = readl(host->ioaddr + SDHCI_ACMD12_ERR);
@@ -761,6 +765,7 @@  static void esdhc_post_tuning(struct sdhci_host *host)
 
 	reg = readl(host->ioaddr + ESDHC_MIX_CTRL);
 	reg &= ~ESDHC_MIX_CTRL_EXE_TUNE;
+	reg |= ESDHC_MIX_CTRL_AUTO_TUNE_EN;
 	writel(reg, host->ioaddr + ESDHC_MIX_CTRL);
 }