* Re: MMC timeout issue on 4.6 kernel
From: Adrian Hunter @ 2016-10-05 5:49 UTC (permalink / raw)
To: Sai Krishna Potthuri, linux-mmc@vger.kernel.org
Cc: Ulf Hansson, Shawn Lin, dianders, Soren Brinkmann
In-Reply-To: <f44317a2-2238-8906-608c-3f45562a2c83@intel.com>
On 04/10/16 15:59, Adrian Hunter wrote:
> On 04/10/16 15:41, Sai Krishna Potthuri wrote:
>> Hi,
>>
>>>
>>> You should use git bisect to find the failing commit.
>> It is failing after many successful runs, issue occurring in regression sometimes after 4 to 5hrs.
>> So, it is taking lot of time to test a single commit. Anyway I will do this if I don't have any
>> Other option.
>>>
>>> What driver is it?
>> sdhci arasan driver(sdhci-of-arasan.c)
>
> So let's cc some of the people who have worked on it.
>
>>>
>>> Does the problem still happen on 4.8? Or stable kernels?
>> Tried on 4.7 kernel, didn't see the issue.
>
> What about 4.5 stable? i.e. 4.5.7
Actually 4.6.7 i.e. the stable version of the failing kernel.
>
>>
>> Regards
>> Sai Krishna
>>>
>>>>
>>>> Regards
>>>> Sai Krishna
>>>>
>>>>> -----Original Message-----
>>>>> From: Sai Krishna Potthuri
>>>>> Sent: Saturday, October 01, 2016 1:59 PM
>>>>> To: 'linux-mmc@vger.kernel.org' <linux-mmc@vger.kernel.org>
>>>>> Cc: 'Ulf Hansson' <ulf.hansson@linaro.org>
>>>>> Subject: RE: MMC timeout issue on 4.6 kernel
>>>>>
>>>>> Hi,
>>>>>
>>>>> Any help
>>>>>
>>>>> Regards
>>>>> Sai Krishna
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Sai Krishna Potthuri
>>>>>> Sent: Monday, September 26, 2016 10:29 PM
>>>>>> To: linux-mmc@vger.kernel.org
>>>>>> Cc: Ulf Hansson <ulf.hansson@linaro.org>
>>>>>> Subject: MMC timeout issue on 4.6 kernel
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> With 4.6 kernel, I am doing regression test on SD which does following
>>> things.
>>>>>> 1. Mount SD card.
>>>>>> 2. Read and write random 1MB data.
>>>>>> 3. Reboot the board.
>>>>>>
>>>>>> I am facing following error while reading the data from the SD card.
>>>>>>
>>>>>> mmc0: Timeout waiting for hardware interrupt.
>>>>>> mmcblk0: error -110 transferring data, sector 8194, nr 2, cmd response
>>>>>> 0x900, card status 0xb00
>>>>>> mmc0: tried to reset card
>>>>>> mmc0: Timeout waiting for hardware interrupt.
>>>>>> mmcblk0: error -110 transferring data, sector 8194, nr 2, cmd response
>>>>>> 0x900, card status 0xb00
>>>>>> mmcblk0: retrying using single block read
>>>>>> mmc0: Timeout waiting for hardware interrupt.
>>>>>> mmcblk0: error -110 transferring data, sector 8194, nr 2, cmd response
>>>>>> 0x900, card status 0x0
>>>>>> blk_update_request: I/O error, dev mmcblk0, sector 8194
>>>>>> mmc0: Timeout waiting for hardware interrupt.
>>>>>> mmcblk0: error -110 transferring data, sector 8195, nr 1, cmd response
>>>>>> 0x900, card status 0x0
>>>>>> blk_update_request: I/O error, dev mmcblk0, sector 8195 EXT2-fs
>>>>> (mmcblk0p1):
>>>>>> error: unable to read superblock
>>>>>> mmc0: Timeout waiting for hardware interrupt.
>>>>>> mmcblk0: error -110 transferring data, sector 16387, nr 61, cmd
>>>>>> response 0x900, card status 0xb00
>>>>>> mmc0: tried to reset card
>>>>>>
>>>>>> Getting this error once in a while in regression test after several runs.
>>>>>> I am not seeing this issue with 4.5 kernel.
>>>>>> Please let me know if anyone has seen this issue.
>>>>>>
>>>>>> Regards
>>>>>> Sai Krishna
>>>> --
>>>> 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
>>>>
>>
>>
>>
>> This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
>>
>>
>
>
^ permalink raw reply
* [PATCH] mmc: sdhci-pci-core: Tuning mode support for HS200 on AMD Platforms
From: Shyam Sundar S K @ 2016-10-04 8:42 UTC (permalink / raw)
To: adrian.hunter, ulf.hansson
Cc: linux-mmc, Sen, Pankaj, Shah, Nehal-bakulchandra,
Agrawal, Nitesh-kumar
This patch adds support for HS200 tuning mode on AMD eMMC-4.5.1
Reviewed-by: Sen, Pankaj <Pankaj.Sen@amd.com>
Reviewed-by: Shah, Nehal-bakulchandra <Nehal-bakulchandra.Shah@amd.com>
Signed-off-by: S-k, Shyam-sundar <Shyam-sundar.S-k@amd.com>
---
drivers/mmc/host/sdhci-pci-core.c | 182 +++++++++++++++++++++++++++++++++++++-
1 file changed, 180 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci-pci-core.c b/drivers/mmc/host/sdhci-pci-core.c
index 897cfd2..5893ec4 100644
--- a/drivers/mmc/host/sdhci-pci-core.c
+++ b/drivers/mmc/host/sdhci-pci-core.c
@@ -734,6 +734,7 @@ static const struct sdhci_pci_fixes sdhci_via = {
.probe = via_probe,
};
+
static int rtsx_probe_slot(struct sdhci_pci_slot *slot)
{
slot->host->mmc->caps2 |= MMC_CAP2_HS200;
@@ -755,6 +756,172 @@ enum amd_chipset_gen {
AMD_CHIPSET_UNKNOWN,
};
+struct tuning_descriptor {
+ unsigned char tune_around;
+ bool this_tune_ok;
+ bool last_tune_ok;
+ bool valid_front_end;
+ unsigned char valid_front;
+ unsigned char valid_window_max;
+ unsigned char tune_low_max;
+ unsigned char tune_low;
+ unsigned char valid_window;
+ unsigned char tune_result;
+};
+
+static struct sdhci_ops sdhci_pci_ops;
+static struct tuning_descriptor tdescriptor;
+
+static int tuning_reset(struct sdhci_host *host)
+{
+ unsigned int val;
+ unsigned long flags;
+
+ spin_lock_irqsave(&host->lock, flags);
+
+ val = sdhci_readw(host, SDHCI_HOST_CONTROL2);
+ val |= SDHCI_CTRL_PRESET_VAL_ENABLE | SDHCI_CTRL_EXEC_TUNING;
+ sdhci_writew(host, val, SDHCI_HOST_CONTROL2);
+
+ val = sdhci_readw(host, SDHCI_HOST_CONTROL2);
+ val &= ~SDHCI_CTRL_EXEC_TUNING;
+ sdhci_writew(host, val, SDHCI_HOST_CONTROL2);
+
+ spin_unlock_irqrestore(&host->lock, flags);
+
+ return 0;
+}
+
+static int config_tuning_phase(struct sdhci_host *host, unsigned char phase)
+{
+ struct sdhci_pci_slot *slot = sdhci_priv(host);
+ struct pci_dev *pdev = slot->chip->pdev;
+ unsigned int val;
+ unsigned long flags;
+
+ spin_lock_irqsave(&host->lock, flags);
+
+ pci_read_config_dword(pdev, 0xb8, &val);
+ val &= ~0x1f;
+ val |= (0x10800 | (phase << 1));
+ pci_write_config_dword(pdev, 0xb8, val);
+
+ spin_unlock_irqrestore(&host->lock, flags);
+
+ return 0;
+}
+
+static int find_good_phase(struct sdhci_host *host)
+{
+ struct tuning_descriptor *td = &tdescriptor;
+ struct sdhci_pci_slot *slot = sdhci_priv(host);
+ struct pci_dev *pdev = slot->chip->pdev;
+ unsigned int val;
+ unsigned long flags;
+
+ spin_lock_irqsave(&host->lock, flags);
+
+ if (td->this_tune_ok == false)
+ td->valid_front_end = 1;
+
+ if (td->valid_front_end)
+ td->valid_front = td->valid_front;
+ else if (td->this_tune_ok)
+ td->valid_front = td->valid_front + 1;
+
+ if ((!td->this_tune_ok && td->last_tune_ok) ||
+ (td->tune_around == 11)) {
+
+ if (td->valid_window > td->valid_window_max) {
+ td->valid_window_max = td->valid_window;
+ td->tune_low_max = td->tune_low;
+ }
+ }
+
+ if (td->this_tune_ok && (!td->last_tune_ok))
+ td->tune_low = td->tune_around;
+ if (!td->this_tune_ok && td->last_tune_ok)
+ td->valid_window = 0x0;
+ else if (td->this_tune_ok)
+ td->valid_window = td->valid_window + 1;
+
+ td->last_tune_ok = td->this_tune_ok;
+
+ if (td->tune_around == 11) {
+ if ((td->valid_front + td->valid_window) >
+ td->valid_window_max) {
+ if (td->valid_front > td->valid_window)
+ td->tune_result = ((td->valid_front -
+ td->valid_window) >> 1);
+ else
+ td->tune_result = td->tune_low +
+ ((td->valid_window + td->valid_front) >> 1);
+ } else {
+ td->tune_result = td->tune_low_max +
+ (td->valid_window_max>>1);
+ }
+
+
+ if (td->tune_result > 0x0b)
+ td->tune_result = 0x0b;
+
+ pci_read_config_dword(pdev, 0xb8, &val);
+ val &= ~0x1f;
+ val |= (0x10800 | (td->tune_result<<1));
+ pci_write_config_dword(pdev, 0xb8, val);
+ }
+
+ spin_unlock_irqrestore(&host->lock, flags);
+
+ return 0;
+}
+
+static int amd_execute_tuning(struct sdhci_host *host, u32 opcode)
+{
+ struct tuning_descriptor *td = &tdescriptor;
+ u8 ctrl;
+
+ tuning_reset(host);
+ memset(td, 0x0, sizeof(struct tuning_descriptor));
+
+ if (host->quirks2 & SDHCI_QUIRK2_CLEAR_TRANSFERMODE_REG_BEFORE_CMD)
+ opcode = MMC_SEND_TUNING_BLOCK_HS200;
+
+ for (td->tune_around = 0; td->tune_around < 12; td->tune_around++) {
+
+ config_tuning_phase(host, td->tune_around);
+
+ if (mmc_send_tuning(host->mmc, opcode, NULL)) {
+ td->this_tune_ok = false;
+ host->mmc->need_retune = 0;
+ mdelay(4);
+ ctrl = SDHCI_RESET_CMD | SDHCI_RESET_DATA;
+ sdhci_writeb(host, ctrl, SDHCI_SOFTWARE_RESET);
+ } else {
+ td->this_tune_ok = true;
+ }
+
+ find_good_phase(host);
+ }
+
+ host->mmc->retune_period = 0;
+
+ return 0;
+}
+
+static int amd_enable_manual_tuning(struct sdhci_pci_slot *slot)
+{
+ struct pci_dev *pdev = slot->chip->pdev;
+ unsigned int val;
+
+ pci_read_config_dword(pdev, 0xd0, &val);
+ val &= 0xffffffcf;
+ val |= 0x30;
+ pci_write_config_dword(pdev, 0xd0, val);
+
+ return 0;
+}
+
static int amd_probe(struct sdhci_pci_chip *chip)
{
struct pci_dev *smbus_dev;
@@ -779,14 +946,25 @@ static int amd_probe(struct sdhci_pci_chip *chip)
if ((gen == AMD_CHIPSET_BEFORE_ML) || (gen == AMD_CHIPSET_CZ)) {
chip->quirks2 |= SDHCI_QUIRK2_CLEAR_TRANSFERMODE_REG_BEFORE_CMD;
- chip->quirks2 |= SDHCI_QUIRK2_BROKEN_HS200;
}
return 0;
}
+static int amd_probe_slot(struct sdhci_pci_slot *slot)
+{
+ struct sdhci_host *host = slot->host;
+
+ if (host->quirks2 & SDHCI_QUIRK2_CLEAR_TRANSFERMODE_REG_BEFORE_CMD) {
+ sdhci_pci_ops.platform_execute_tuning = amd_execute_tuning;
+ amd_enable_manual_tuning(slot);
+ }
+ return 0;
+}
+
static const struct sdhci_pci_fixes sdhci_amd = {
.probe = amd_probe,
+ .probe_slot = amd_probe_slot,
};
static const struct pci_device_id pci_ids[] = {
@@ -1397,7 +1575,7 @@ static int sdhci_pci_select_drive_strength(struct sdhci_host *host,
card_drv, drv_type);
}
-static const struct sdhci_ops sdhci_pci_ops = {
+static struct sdhci_ops sdhci_pci_ops = {
.set_clock = sdhci_set_clock,
.enable_dma = sdhci_pci_enable_dma,
.set_bus_width = sdhci_pci_set_bus_width,
--
2.7.4
^ permalink raw reply related
* Re: MMC timeout issue on 4.6 kernel
From: Adrian Hunter @ 2016-10-04 12:59 UTC (permalink / raw)
To: Sai Krishna Potthuri, linux-mmc@vger.kernel.org
Cc: Ulf Hansson, Shawn Lin, dianders, Soren Brinkmann
In-Reply-To: <4FF8F58FAA9D5D4193D4E554E4352C591CCBF92A@XAP-PVEXMBX02.xlnx.xilinx.com>
On 04/10/16 15:41, Sai Krishna Potthuri wrote:
> Hi,
>
>>
>> You should use git bisect to find the failing commit.
> It is failing after many successful runs, issue occurring in regression sometimes after 4 to 5hrs.
> So, it is taking lot of time to test a single commit. Anyway I will do this if I don't have any
> Other option.
>>
>> What driver is it?
> sdhci arasan driver(sdhci-of-arasan.c)
So let's cc some of the people who have worked on it.
>>
>> Does the problem still happen on 4.8? Or stable kernels?
> Tried on 4.7 kernel, didn't see the issue.
What about 4.5 stable? i.e. 4.5.7
>
> Regards
> Sai Krishna
>>
>>>
>>> Regards
>>> Sai Krishna
>>>
>>>> -----Original Message-----
>>>> From: Sai Krishna Potthuri
>>>> Sent: Saturday, October 01, 2016 1:59 PM
>>>> To: 'linux-mmc@vger.kernel.org' <linux-mmc@vger.kernel.org>
>>>> Cc: 'Ulf Hansson' <ulf.hansson@linaro.org>
>>>> Subject: RE: MMC timeout issue on 4.6 kernel
>>>>
>>>> Hi,
>>>>
>>>> Any help
>>>>
>>>> Regards
>>>> Sai Krishna
>>>>
>>>>> -----Original Message-----
>>>>> From: Sai Krishna Potthuri
>>>>> Sent: Monday, September 26, 2016 10:29 PM
>>>>> To: linux-mmc@vger.kernel.org
>>>>> Cc: Ulf Hansson <ulf.hansson@linaro.org>
>>>>> Subject: MMC timeout issue on 4.6 kernel
>>>>>
>>>>> Hi,
>>>>>
>>>>> With 4.6 kernel, I am doing regression test on SD which does following
>> things.
>>>>> 1. Mount SD card.
>>>>> 2. Read and write random 1MB data.
>>>>> 3. Reboot the board.
>>>>>
>>>>> I am facing following error while reading the data from the SD card.
>>>>>
>>>>> mmc0: Timeout waiting for hardware interrupt.
>>>>> mmcblk0: error -110 transferring data, sector 8194, nr 2, cmd response
>>>>> 0x900, card status 0xb00
>>>>> mmc0: tried to reset card
>>>>> mmc0: Timeout waiting for hardware interrupt.
>>>>> mmcblk0: error -110 transferring data, sector 8194, nr 2, cmd response
>>>>> 0x900, card status 0xb00
>>>>> mmcblk0: retrying using single block read
>>>>> mmc0: Timeout waiting for hardware interrupt.
>>>>> mmcblk0: error -110 transferring data, sector 8194, nr 2, cmd response
>>>>> 0x900, card status 0x0
>>>>> blk_update_request: I/O error, dev mmcblk0, sector 8194
>>>>> mmc0: Timeout waiting for hardware interrupt.
>>>>> mmcblk0: error -110 transferring data, sector 8195, nr 1, cmd response
>>>>> 0x900, card status 0x0
>>>>> blk_update_request: I/O error, dev mmcblk0, sector 8195 EXT2-fs
>>>> (mmcblk0p1):
>>>>> error: unable to read superblock
>>>>> mmc0: Timeout waiting for hardware interrupt.
>>>>> mmcblk0: error -110 transferring data, sector 16387, nr 61, cmd
>>>>> response 0x900, card status 0xb00
>>>>> mmc0: tried to reset card
>>>>>
>>>>> Getting this error once in a while in regression test after several runs.
>>>>> I am not seeing this issue with 4.5 kernel.
>>>>> Please let me know if anyone has seen this issue.
>>>>>
>>>>> Regards
>>>>> Sai Krishna
>>> --
>>> 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
>>>
>
>
>
> This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
>
>
^ permalink raw reply
* RE: MMC timeout issue on 4.6 kernel
From: Sai Krishna Potthuri @ 2016-10-04 12:41 UTC (permalink / raw)
To: Adrian Hunter, linux-mmc@vger.kernel.org; +Cc: Ulf Hansson
In-Reply-To: <9c0524cd-ae12-4d5c-341c-2ec509a8b3b9@intel.com>
Hi,
>
> You should use git bisect to find the failing commit.
It is failing after many successful runs, issue occurring in regression sometimes after 4 to 5hrs.
So, it is taking lot of time to test a single commit. Anyway I will do this if I don't have any
Other option.
>
> What driver is it?
sdhci arasan driver(sdhci-of-arasan.c)
>
> Does the problem still happen on 4.8? Or stable kernels?
Tried on 4.7 kernel, didn't see the issue.
Regards
Sai Krishna
>
> >
> > Regards
> > Sai Krishna
> >
> >> -----Original Message-----
> >> From: Sai Krishna Potthuri
> >> Sent: Saturday, October 01, 2016 1:59 PM
> >> To: 'linux-mmc@vger.kernel.org' <linux-mmc@vger.kernel.org>
> >> Cc: 'Ulf Hansson' <ulf.hansson@linaro.org>
> >> Subject: RE: MMC timeout issue on 4.6 kernel
> >>
> >> Hi,
> >>
> >> Any help
> >>
> >> Regards
> >> Sai Krishna
> >>
> >>> -----Original Message-----
> >>> From: Sai Krishna Potthuri
> >>> Sent: Monday, September 26, 2016 10:29 PM
> >>> To: linux-mmc@vger.kernel.org
> >>> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> >>> Subject: MMC timeout issue on 4.6 kernel
> >>>
> >>> Hi,
> >>>
> >>> With 4.6 kernel, I am doing regression test on SD which does following
> things.
> >>> 1. Mount SD card.
> >>> 2. Read and write random 1MB data.
> >>> 3. Reboot the board.
> >>>
> >>> I am facing following error while reading the data from the SD card.
> >>>
> >>> mmc0: Timeout waiting for hardware interrupt.
> >>> mmcblk0: error -110 transferring data, sector 8194, nr 2, cmd response
> >>> 0x900, card status 0xb00
> >>> mmc0: tried to reset card
> >>> mmc0: Timeout waiting for hardware interrupt.
> >>> mmcblk0: error -110 transferring data, sector 8194, nr 2, cmd response
> >>> 0x900, card status 0xb00
> >>> mmcblk0: retrying using single block read
> >>> mmc0: Timeout waiting for hardware interrupt.
> >>> mmcblk0: error -110 transferring data, sector 8194, nr 2, cmd response
> >>> 0x900, card status 0x0
> >>> blk_update_request: I/O error, dev mmcblk0, sector 8194
> >>> mmc0: Timeout waiting for hardware interrupt.
> >>> mmcblk0: error -110 transferring data, sector 8195, nr 1, cmd response
> >>> 0x900, card status 0x0
> >>> blk_update_request: I/O error, dev mmcblk0, sector 8195 EXT2-fs
> >> (mmcblk0p1):
> >>> error: unable to read superblock
> >>> mmc0: Timeout waiting for hardware interrupt.
> >>> mmcblk0: error -110 transferring data, sector 16387, nr 61, cmd
> >>> response 0x900, card status 0xb00
> >>> mmc0: tried to reset card
> >>>
> >>> Getting this error once in a while in regression test after several runs.
> >>> I am not seeing this issue with 4.5 kernel.
> >>> Please let me know if anyone has seen this issue.
> >>>
> >>> Regards
> >>> Sai Krishna
> > --
> > 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
> >
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: MMC timeout issue on 4.6 kernel
From: Adrian Hunter @ 2016-10-04 12:20 UTC (permalink / raw)
To: Sai Krishna Potthuri, linux-mmc@vger.kernel.org; +Cc: Ulf Hansson
In-Reply-To: <4FF8F58FAA9D5D4193D4E554E4352C591CCBF88E@XAP-PVEXMBX02.xlnx.xilinx.com>
On 04/10/16 12:03, Sai Krishna Potthuri wrote:
> Hi All,
>
> With further debug, I am seeing the issue only with ADMA2, whereas SDMA and PIO mode are working fine.
> Can anyone help me on this issue?
You should use git bisect to find the failing commit.
What driver is it?
Does the problem still happen on 4.8? Or stable kernels?
>
> Regards
> Sai Krishna
>
>> -----Original Message-----
>> From: Sai Krishna Potthuri
>> Sent: Saturday, October 01, 2016 1:59 PM
>> To: 'linux-mmc@vger.kernel.org' <linux-mmc@vger.kernel.org>
>> Cc: 'Ulf Hansson' <ulf.hansson@linaro.org>
>> Subject: RE: MMC timeout issue on 4.6 kernel
>>
>> Hi,
>>
>> Any help
>>
>> Regards
>> Sai Krishna
>>
>>> -----Original Message-----
>>> From: Sai Krishna Potthuri
>>> Sent: Monday, September 26, 2016 10:29 PM
>>> To: linux-mmc@vger.kernel.org
>>> Cc: Ulf Hansson <ulf.hansson@linaro.org>
>>> Subject: MMC timeout issue on 4.6 kernel
>>>
>>> Hi,
>>>
>>> With 4.6 kernel, I am doing regression test on SD which does following things.
>>> 1. Mount SD card.
>>> 2. Read and write random 1MB data.
>>> 3. Reboot the board.
>>>
>>> I am facing following error while reading the data from the SD card.
>>>
>>> mmc0: Timeout waiting for hardware interrupt.
>>> mmcblk0: error -110 transferring data, sector 8194, nr 2, cmd response
>>> 0x900, card status 0xb00
>>> mmc0: tried to reset card
>>> mmc0: Timeout waiting for hardware interrupt.
>>> mmcblk0: error -110 transferring data, sector 8194, nr 2, cmd response
>>> 0x900, card status 0xb00
>>> mmcblk0: retrying using single block read
>>> mmc0: Timeout waiting for hardware interrupt.
>>> mmcblk0: error -110 transferring data, sector 8194, nr 2, cmd response
>>> 0x900, card status 0x0
>>> blk_update_request: I/O error, dev mmcblk0, sector 8194
>>> mmc0: Timeout waiting for hardware interrupt.
>>> mmcblk0: error -110 transferring data, sector 8195, nr 1, cmd response
>>> 0x900, card status 0x0
>>> blk_update_request: I/O error, dev mmcblk0, sector 8195 EXT2-fs
>> (mmcblk0p1):
>>> error: unable to read superblock
>>> mmc0: Timeout waiting for hardware interrupt.
>>> mmcblk0: error -110 transferring data, sector 16387, nr 61, cmd
>>> response 0x900, card status 0xb00
>>> mmc0: tried to reset card
>>>
>>> Getting this error once in a while in regression test after several runs.
>>> I am not seeing this issue with 4.5 kernel.
>>> Please let me know if anyone has seen this issue.
>>>
>>> Regards
>>> Sai Krishna
> --
> 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
>
^ permalink raw reply
* RE: MMC timeout issue on 4.6 kernel
From: Sai Krishna Potthuri @ 2016-10-04 9:03 UTC (permalink / raw)
To: linux-mmc@vger.kernel.org; +Cc: Ulf Hansson
Hi All,
With further debug, I am seeing the issue only with ADMA2, whereas SDMA and PIO mode are working fine.
Can anyone help me on this issue?
Regards
Sai Krishna
> -----Original Message-----
> From: Sai Krishna Potthuri
> Sent: Saturday, October 01, 2016 1:59 PM
> To: 'linux-mmc@vger.kernel.org' <linux-mmc@vger.kernel.org>
> Cc: 'Ulf Hansson' <ulf.hansson@linaro.org>
> Subject: RE: MMC timeout issue on 4.6 kernel
>
> Hi,
>
> Any help
>
> Regards
> Sai Krishna
>
> > -----Original Message-----
> > From: Sai Krishna Potthuri
> > Sent: Monday, September 26, 2016 10:29 PM
> > To: linux-mmc@vger.kernel.org
> > Cc: Ulf Hansson <ulf.hansson@linaro.org>
> > Subject: MMC timeout issue on 4.6 kernel
> >
> > Hi,
> >
> > With 4.6 kernel, I am doing regression test on SD which does following things.
> > 1. Mount SD card.
> > 2. Read and write random 1MB data.
> > 3. Reboot the board.
> >
> > I am facing following error while reading the data from the SD card.
> >
> > mmc0: Timeout waiting for hardware interrupt.
> > mmcblk0: error -110 transferring data, sector 8194, nr 2, cmd response
> > 0x900, card status 0xb00
> > mmc0: tried to reset card
> > mmc0: Timeout waiting for hardware interrupt.
> > mmcblk0: error -110 transferring data, sector 8194, nr 2, cmd response
> > 0x900, card status 0xb00
> > mmcblk0: retrying using single block read
> > mmc0: Timeout waiting for hardware interrupt.
> > mmcblk0: error -110 transferring data, sector 8194, nr 2, cmd response
> > 0x900, card status 0x0
> > blk_update_request: I/O error, dev mmcblk0, sector 8194
> > mmc0: Timeout waiting for hardware interrupt.
> > mmcblk0: error -110 transferring data, sector 8195, nr 1, cmd response
> > 0x900, card status 0x0
> > blk_update_request: I/O error, dev mmcblk0, sector 8195 EXT2-fs
> (mmcblk0p1):
> > error: unable to read superblock
> > mmc0: Timeout waiting for hardware interrupt.
> > mmcblk0: error -110 transferring data, sector 16387, nr 61, cmd
> > response 0x900, card status 0xb00
> > mmc0: tried to reset card
> >
> > Getting this error once in a while in regression test after several runs.
> > I am not seeing this issue with 4.5 kernel.
> > Please let me know if anyone has seen this issue.
> >
> > Regards
> > Sai Krishna
^ permalink raw reply
* Re: [PATCH v4 3/9] mmc: sdhci-msm: add pltfm_data support to get clk-rates from DT
From: Ritesh Harjani @ 2016-10-04 9:33 UTC (permalink / raw)
To: Stephen Boyd
Cc: adrian.hunter, ulf.hansson, linux-mmc, shawn.lin, linux-arm-msm,
georgi.djakov, alex.lemberg, mateusz.nowak, Yuliy.Izrailov,
asutoshd, david.griego, stummala, venkatg, pramod.gurav,
bjorn.andersson, devicetree
In-Reply-To: <f40ac4e7-7e12-26e2-254a-99b6e5d25cd3@codeaurora.org>
Hi Stephen/Adrian,
Let me give a little background on this. We would need more suggestions
and opinion on this. Sorry for the delay it took.
Background -
Below change adds clk-rates DT entry since sdhci-msm driver uses this
clk-rates table to find the nearest *floor* value of clock (this clock
request comes will come from core layer) supported by msm platform.
Currently we don't have an API from clock driver which we can use it
here to find these values(supported by msm platforms) and call for
clk_set_rate. Hence the custom DT entry to have a table.
Please let us know if there is an API to find the floor value of clock
from clock driver. I tried clk_set_max_rate, but it is not giving
expected output (at least for msm platforms).
Comment-
The request from Stephen was to check if we could utilize OppV2
framework since it provides an API - dev_pm_opp_find_freq_floor.
Also to check if we could get it done from existing clock driver APIs.
Please correct me I am missing anything.
Concern and opinion?
1. What about if there are more clocks getting added to sdhci DT node?
I see the Oppv2 framework taking device pointer as 1st argument. In
cases where we have more than 1 clocks per device, how will Oppv2 handle
this?
2. Here the concern is that shifting to Oppv2 framework only for use of
this 1 API does not seems very useful. In case if there exist a clock
driver API to do this, we may not have anything to be populated in DT.
Opinion and suggestions please?
Is it ok to continue to use clk-rates DT entry here for this case?
Regards
Ritesh
On 9/12/2016 11:47 AM, Ritesh Harjani wrote:
> Hi Stephen,
>
>
> On 9/7/2016 9:44 PM, Stephen Boyd wrote:
>> On 08/30, Ritesh Harjani wrote:
>>> On 8/26/2016 3:57 AM, Stephen Boyd wrote:
>>>> On 08/24, Ritesh Harjani wrote:
>>>>> This adds support for sdhc-msm controllers to get supported
>>>>> clk-rates from DT. sdhci-msm would need it's own set_clock
>>>>> ops to be implemented. For this, supported clk-rates needs
>>>>> to be populated in sdhci_msm_pltfm_data.
>>>>>
>>>>> Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
>>>>> ---
>>>>
>>>> Please include the DT binding review list in binding updates.
> Sure, will do it.
>
>>>>
>>>>> .../devicetree/bindings/mmc/sdhci-msm.txt | 1 +
>>>>> drivers/mmc/host/sdhci-msm.c | 60
>>>>> ++++++++++++++++++++++
>>>>> 2 files changed, 61 insertions(+)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
>>>>> b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
>>>>> index 485483a..6a83b38 100644
>>>>> --- a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
>>>>> +++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
>>>>> @@ -17,6 +17,7 @@ Required properties:
>>>>> "iface" - Main peripheral bus clock (PCLK/HCLK - AHB Bus clock)
>>>>> (required)
>>>>> "core" - SDC MMC clock (MCLK) (required)
>>>>> "bus" - SDCC bus voter clock (optional)
>>>>> +- clk-rates: Array of supported GCC clock frequencies for sdhc,
>>>>> Units - Hz.
>>>>>
>>>>
>>>> Why not use OPPv2 binding for this? We already have a way to
>>>> express frequencies for devices with that binding, and we'll need
>>>> to attach voltages to those frequencies at some point in the
>>>> future if we want to handle DVFS on these devices.
>>>>
>>> OPPv2 may not work out in this case. This was also discussed at [1].
>>> These clk-rates are not as per voltage points(or any OPP) but as per
>>> bus speed mode request from higher layer.
>>>
>>
>> That post you link to had a response from Andy that echoed the
>> same sentiment and then no reply.
>>
>> Are they a set of frequencies the device can operate at? Yes. Do
>> they have associated voltages that aren't expressed in this
>> patch? Yes.
>>
>> Perhaps I've missed something though and the index of the array
>> of rates corresponds to some bus speed mode? That isn't clearly
>> expressed in the binding. Do the frequencies come from some spec
>> for those bus speed modes? Either way, I'd like to understand why
>> we need to put frequency tables into DT (hint: the commit text
>> should explain that).
>>
> As discussed offline, I will get back on this.
>
> Regards
> Ritesh
^ permalink raw reply
* Re: [PATCH v9] mmc: OCTEON: Add host driver for OCTEON MMC controller.
From: Steven J. Hill @ 2016-10-04 1:18 UTC (permalink / raw)
To: linux-mips, linux-mmc; +Cc: Ulf Hansson, Mark Rutland, David Daney
In-Reply-To: <836c0ca9-18f0-f6b5-bb79-8d0301d54154@cavium.com>
On 09/19/2016 03:24 PM, Steven J. Hill wrote:
> The OCTEON MMC controller is currently found on cn61XX and cn71XX
> devices. Device parameters are configured from device tree data.
> eMMC, MMC and SD devices are supported. Tested on Cavium CN7130.
>
> Signed-off-by: Steven J. Hill <steven.hill@cavium.com>
> Acked-by: David Daney <david.daney@cavium.com>
>
Hello.
Have any MMC maintainers gotten a chance to review our driver now
that v4.8 is out? Thanks.
Steve
^ permalink raw reply
* Re: [RFC 1/2] sdhci: Add device tree property sd-broken-highspeed
From: Rob Herring @ 2016-10-03 17:37 UTC (permalink / raw)
To: Zach Brown
Cc: ulf.hansson-QSEj5FYQhm4dnm+yROfE0A,
adrian.hunter-ral2JQCrhuEAvxtiuMwx3w, mark.rutland-5wv7dgnIgG8,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1474660869-15532-2-git-send-email-zach.brown-acOepvfBmUk@public.gmane.org>
On Fri, Sep 23, 2016 at 03:01:08PM -0500, Zach Brown wrote:
> Certain board configurations can make highspeed malfunction due to
> timing issues. In these cases a way is needed to force the controller
> and card into standard speed even if they otherwise appear to be capable
> of highspeed.
>
> The sd-broken-highspeed property will let the sdhci driver know that
> highspeed will not work.
>
> Signed-off-by: Zach Brown <zach.brown-acOepvfBmUk@public.gmane.org>
> ---
> Documentation/devicetree/bindings/mmc/mmc.txt | 2 ++
> 1 file changed, 2 insertions(+)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] mmc: Hynix: add QUIRK_NOTIFY_POWEROFF_ON_SLEEP
From: Thierry Escande @ 2016-10-03 14:19 UTC (permalink / raw)
To: Ulf Hansson; +Cc: linux-mmc
From: zhaojohn <john.zhao@intel.com>
Hynix eMMC devices sometimes take 50% longer to resume from sleep.
Based on a recommendation from Hynix, send a Power-Off Notification
before going to S3 to restore a resume time consistently within spec.
Signed-off-by: zhaojohn <john.zhao@intel.com>
Signed-off-by: Arindam Roy <arindam.roy@intel.com>
Tested-by: Freddy Paul <freddy.paul@intel.com>
Reviewed-by: Icarus W Sparry <icarus.w.sparry@intel.com>
Reviewed-by: Marc Herbert <marc.herbert@intel.com>
Reviewed-by: Eric Caruso <ejcaruso@chromium.org>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Thierry Escande <thierry.escande@collabora.com>
---
drivers/mmc/card/block.c | 8 ++++++++
drivers/mmc/core/mmc.c | 8 +++++++-
include/linux/mmc/card.h | 2 ++
3 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 2206d44..cbc2d97 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -2572,6 +2572,14 @@ static const struct mmc_fixup blk_fixups[] =
MMC_FIXUP("V10016", CID_MANFID_KINGSTON, CID_OEMID_ANY, add_quirk_mmc,
MMC_QUIRK_TRIM_BROKEN),
+ /*
+ * Hynix eMMC devices sometimes take 50% longer to resume from sleep.
+ * Based on a recommendation from Hynix, send a Power-Off Notification
+ * before going to S3 to restore a resume time consistently within spec.
+ */
+ MMC_FIXUP(CID_NAME_ANY, CID_MANFID_HYNIX, CID_OEMID_ANY, add_quirk_mmc,
+ MMC_QUIRK_NOTIFY_POWEROFF_ON_SLEEP),
+
END_FIXUP
};
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index f2d185c..46a4562 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1925,8 +1925,14 @@ static int _mmc_suspend(struct mmc_host *host, bool is_suspend)
if (mmc_can_poweroff_notify(host->card) &&
((host->caps2 & MMC_CAP2_FULL_PWR_CYCLE) || !is_suspend))
err = mmc_poweroff_notify(host->card, notify_type);
- else if (mmc_can_sleep(host->card))
+ else if (mmc_can_sleep(host->card)) {
+ if (host->card->quirks & MMC_QUIRK_NOTIFY_POWEROFF_ON_SLEEP) {
+ err = mmc_poweroff_notify(host->card, notify_type);
+ if (err)
+ goto out;
+ }
err = mmc_sleep(host);
+ }
else if (!mmc_host_is_spi(host))
err = mmc_deselect_cards(host);
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index d8673ca..30e34b0 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -281,6 +281,8 @@ struct mmc_card {
#define MMC_QUIRK_BROKEN_IRQ_POLLING (1<<11) /* Polling SDIO_CCCR_INTx could create a fake interrupt */
#define MMC_QUIRK_TRIM_BROKEN (1<<12) /* Skip trim */
#define MMC_QUIRK_BROKEN_HPI (1<<13) /* Disable broken HPI support */
+#define MMC_QUIRK_NOTIFY_POWEROFF_ON_SLEEP \
+ (1<<14) /* Poweroff notification*/
unsigned int erase_size; /* erase size in sectors */
--
2.7.4
^ permalink raw reply related
* Enabling MMC BKOPs in kernel based on host caps
From: Ravikumar Kattekola @ 2016-10-03 10:43 UTC (permalink / raw)
To: linux-mmc
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="y", Size: 1042 bytes --]
Hi all,
I’ve seen an eMMC failure due to pending background operations on a certain OMAP device since bkops enable bit was not set.
Further investigation showed me that someone already posted patch to enable Background operations in kernel based on a host capability check (Caps2 & BK_OPS_EN)
but was turned down quoting that it should be enabled from user space using mmc-utils.
Enabling this would add one additional check for exception event in the response R1 or R1B (only on hosts that explicitly set BK_OPS_EN in caps2).
But not enabling this could lead to a system failure especially when the Filesystem is on eMMC and the card stops responding due to pending critical bkops.
I would like to ask for expert opinion on ‘why is it a bad idea to enable bkops in kernel?’
It’s a one time programmable bit but if it helps in keeping system functional why not do it?
I haven’t measured the performance impact but I don’t see a reason for major drop because the frequency of critical bkops events would be less.
Regards,
RK
^ permalink raw reply
* [PATCH] mmc: core, annotate cmd_hdr as __le32
From: Jiri Slaby @ 2016-10-03 8:58 UTC (permalink / raw)
To: ulf.hansson; +Cc: linux-kernel, Jiri Slaby, linux-mmc
Commit f68381a70b (mmc: block: fix packed command header endianness)
correctly fixed endianness handling of packed_cmd_hdr in
mmc_blk_packed_hdr_wrq_prep.
But now, sparse complains about incorrect types:
drivers/mmc/card/block.c:1613:27: sparse: incorrect type in assignment (different base types)
drivers/mmc/card/block.c:1613:27: expected unsigned int [unsigned] [usertype] <noident>
drivers/mmc/card/block.c:1613:27: got restricted __le32 [usertype] <noident>
...
So annotate cmd_hdr properly using __le32 to make everyone happy.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: linux-mmc@vger.kernel.org
---
drivers/mmc/card/block.c | 2 +-
drivers/mmc/card/queue.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index c3335112e68c..9b71414526e7 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -1786,7 +1786,7 @@ static void mmc_blk_packed_hdr_wrq_prep(struct mmc_queue_req *mqrq,
struct mmc_blk_data *md = mq->data;
struct mmc_packed *packed = mqrq->packed;
bool do_rel_wr, do_data_tag;
- u32 *packed_cmd_hdr;
+ __le32 *packed_cmd_hdr;
u8 hdr_blocks;
u8 i = 1;
diff --git a/drivers/mmc/card/queue.h b/drivers/mmc/card/queue.h
index 3c15a75bae86..342f1e3f301e 100644
--- a/drivers/mmc/card/queue.h
+++ b/drivers/mmc/card/queue.h
@@ -31,7 +31,7 @@ enum mmc_packed_type {
struct mmc_packed {
struct list_head list;
- u32 cmd_hdr[1024];
+ __le32 cmd_hdr[1024];
unsigned int blocks;
u8 nr_entries;
u8 retries;
--
2.10.0
^ permalink raw reply related
* RE: MMC timeout issue on 4.6 kernel
From: Sai Krishna Potthuri @ 2016-10-01 8:29 UTC (permalink / raw)
To: linux-mmc@vger.kernel.org; +Cc: Ulf Hansson
Hi,
Any help
Regards
Sai Krishna
> -----Original Message-----
> From: Sai Krishna Potthuri
> Sent: Monday, September 26, 2016 10:29 PM
> To: linux-mmc@vger.kernel.org
> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> Subject: MMC timeout issue on 4.6 kernel
>
> Hi,
>
> With 4.6 kernel, I am doing regression test on SD which does following things.
> 1. Mount SD card.
> 2. Read and write random 1MB data.
> 3. Reboot the board.
>
> I am facing following error while reading the data from the SD card.
>
> mmc0: Timeout waiting for hardware interrupt.
> mmcblk0: error -110 transferring data, sector 8194, nr 2, cmd response 0x900,
> card status 0xb00
> mmc0: tried to reset card
> mmc0: Timeout waiting for hardware interrupt.
> mmcblk0: error -110 transferring data, sector 8194, nr 2, cmd response 0x900,
> card status 0xb00
> mmcblk0: retrying using single block read
> mmc0: Timeout waiting for hardware interrupt.
> mmcblk0: error -110 transferring data, sector 8194, nr 2, cmd response 0x900,
> card status 0x0
> blk_update_request: I/O error, dev mmcblk0, sector 8194
> mmc0: Timeout waiting for hardware interrupt.
> mmcblk0: error -110 transferring data, sector 8195, nr 1, cmd response 0x900,
> card status 0x0
> blk_update_request: I/O error, dev mmcblk0, sector 8195 EXT2-fs (mmcblk0p1):
> error: unable to read superblock
> mmc0: Timeout waiting for hardware interrupt.
> mmcblk0: error -110 transferring data, sector 16387, nr 61, cmd response
> 0x900, card status 0xb00
> mmc0: tried to reset card
>
> Getting this error once in a while in regression test after several runs.
> I am not seeing this issue with 4.5 kernel.
> Please let me know if anyone has seen this issue.
>
> Regards
> Sai Krishna
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
^ permalink raw reply
* [RFC PATCH v2 4/4] mmc: dw_mmc-rockchip: disable biu clk and genpd if possible
From: Shawn Lin @ 2016-09-30 8:48 UTC (permalink / raw)
To: Jaehoon Chung, Ulf Hansson
Cc: linux-mmc, Doug Anderson, linux-rockchip, Shawn Lin
In-Reply-To: <1475225317-2815-1-git-send-email-shawn.lin@rock-chips.com>
We could disable biu clk and power-off genpd if gpio
card detect available.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
---
drivers/mmc/host/dw_mmc-rockchip.c | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/dw_mmc-rockchip.c b/drivers/mmc/host/dw_mmc-rockchip.c
index 3ad041c..e7b3b6d 100644
--- a/drivers/mmc/host/dw_mmc-rockchip.c
+++ b/drivers/mmc/host/dw_mmc-rockchip.c
@@ -13,6 +13,7 @@
#include <linux/mmc/host.h>
#include <linux/mmc/dw_mmc.h>
#include <linux/of_address.h>
+#include <linux/mmc/slot-gpio.h>
#include <linux/pm_runtime.h>
#include <linux/slab.h>
@@ -366,14 +367,29 @@ static int dw_mci_rockchip_remove(struct platform_device *pdev)
static int dw_mci_rockchip_runtime_suspend(struct device *dev)
{
struct dw_mci *host = dev_get_drvdata(dev);
+ int ret;
- return dw_mci_runtime_suspend(host);
+ ret = dw_mci_runtime_suspend(host);
+ if (ret)
+ return ret;
+
+ if (mmc_can_gpio_cd(host->slot[0]->mmc)) {
+ clk_disable_unprepare(host->biu_clk);
+ pm_runtime_put(dev);
+ }
+
+ return 0;
}
static int dw_mci_rockchip_runtime_resume(struct device *dev)
{
struct dw_mci *host = dev_get_drvdata(dev);
+ if (mmc_can_gpio_cd(host->slot[0]->mmc)) {
+ pm_runtime_get_sync(dev);
+ clk_prepare_enable(host->biu_clk);
+ }
+
return dw_mci_runtime_resume(host);
}
#endif /* CONFIG_PM */
--
2.3.7
^ permalink raw reply related
* [RFC PATCH v2 3/4] mmc: core: expose the capability of gpio card detect
From: Shawn Lin @ 2016-09-30 8:48 UTC (permalink / raw)
To: Jaehoon Chung, Ulf Hansson
Cc: linux-mmc, Doug Anderson, linux-rockchip, Shawn Lin
In-Reply-To: <1475225317-2815-1-git-send-email-shawn.lin@rock-chips.com>
Add new helper API mmc_can_gpio_cd for slot-gpio to make
host drivers know whether it supports gpio card detect.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
---
drivers/mmc/core/slot-gpio.c | 8 ++++++++
include/linux/mmc/slot-gpio.h | 1 +
2 files changed, 9 insertions(+)
diff --git a/drivers/mmc/core/slot-gpio.c b/drivers/mmc/core/slot-gpio.c
index 27117ba..babe591 100644
--- a/drivers/mmc/core/slot-gpio.c
+++ b/drivers/mmc/core/slot-gpio.c
@@ -258,6 +258,14 @@ int mmc_gpiod_request_cd(struct mmc_host *host, const char *con_id,
}
EXPORT_SYMBOL(mmc_gpiod_request_cd);
+bool mmc_can_gpio_cd(struct mmc_host *host)
+{
+ struct mmc_gpio *ctx = host->slot.handler_priv;
+
+ return ctx->cd_gpio ? true : false;
+}
+EXPORT_SYMBOL(mmc_can_gpio_cd);
+
/**
* mmc_gpiod_request_ro - request a gpio descriptor for write protection
* @host: mmc host
diff --git a/include/linux/mmc/slot-gpio.h b/include/linux/mmc/slot-gpio.h
index 3945a8c..a7972cd 100644
--- a/include/linux/mmc/slot-gpio.h
+++ b/include/linux/mmc/slot-gpio.h
@@ -29,5 +29,6 @@ int mmc_gpiod_request_ro(struct mmc_host *host, const char *con_id,
void mmc_gpio_set_cd_isr(struct mmc_host *host,
irqreturn_t (*isr)(int irq, void *dev_id));
void mmc_gpiod_request_cd_irq(struct mmc_host *host);
+bool mmc_can_gpio_cd(struct mmc_host *host);
#endif
--
2.3.7
^ permalink raw reply related
* [RFC PATCH v2 2/4] mmc: dw_mmc-rockchip: add runtime PM support
From: Shawn Lin @ 2016-09-30 8:48 UTC (permalink / raw)
To: Jaehoon Chung, Ulf Hansson
Cc: linux-mmc, Doug Anderson, linux-rockchip, Shawn Lin
In-Reply-To: <1475225317-2815-1-git-send-email-shawn.lin@rock-chips.com>
This patch adds runtime PM support for dw_mmc-rockchip.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
---
drivers/mmc/host/dw_mmc-rockchip.c | 57 ++++++++++++++++++++++++++++++++++++--
1 file changed, 54 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc-rockchip.c b/drivers/mmc/host/dw_mmc-rockchip.c
index 25eae35..3ad041c 100644
--- a/drivers/mmc/host/dw_mmc-rockchip.c
+++ b/drivers/mmc/host/dw_mmc-rockchip.c
@@ -13,6 +13,7 @@
#include <linux/mmc/host.h>
#include <linux/mmc/dw_mmc.h>
#include <linux/of_address.h>
+#include <linux/pm_runtime.h>
#include <linux/slab.h>
#include "dw_mmc.h"
@@ -325,6 +326,7 @@ static int dw_mci_rockchip_probe(struct platform_device *pdev)
{
const struct dw_mci_drv_data *drv_data;
const struct of_device_id *match;
+ int ret;
if (!pdev->dev.of_node)
return -ENODEV;
@@ -332,16 +334,65 @@ static int dw_mci_rockchip_probe(struct platform_device *pdev)
match = of_match_node(dw_mci_rockchip_match, pdev->dev.of_node);
drv_data = match->data;
- return dw_mci_pltfm_register(pdev, drv_data);
+ pm_runtime_get_noresume(&pdev->dev);
+ pm_runtime_set_active(&pdev->dev);
+ pm_runtime_enable(&pdev->dev);
+ pm_runtime_set_autosuspend_delay(&pdev->dev, 50);
+ pm_runtime_use_autosuspend(&pdev->dev);
+
+ ret = dw_mci_pltfm_register(pdev, drv_data);
+ if (ret) {
+ pm_runtime_disable(&pdev->dev);
+ pm_runtime_set_suspended(&pdev->dev);
+ pm_runtime_put_noidle(&pdev->dev);
+ return ret;
+ }
+
+ pm_runtime_put_autosuspend(&pdev->dev);
+
+ return 0;
+}
+
+static int dw_mci_rockchip_remove(struct platform_device *pdev)
+{
+ pm_runtime_get_sync(&pdev->dev);
+ pm_runtime_disable(&pdev->dev);
+ pm_runtime_put_noidle(&pdev->dev);
+
+ return dw_mci_pltfm_remove(pdev);
}
+#ifdef CONFIG_PM
+static int dw_mci_rockchip_runtime_suspend(struct device *dev)
+{
+ struct dw_mci *host = dev_get_drvdata(dev);
+
+ return dw_mci_runtime_suspend(host);
+}
+
+static int dw_mci_rockchip_runtime_resume(struct device *dev)
+{
+ struct dw_mci *host = dev_get_drvdata(dev);
+
+ return dw_mci_runtime_resume(host);
+}
+#endif /* CONFIG_PM */
+
+static const struct dev_pm_ops dw_mci_rockchip_dev_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+ pm_runtime_force_resume)
+ SET_RUNTIME_PM_OPS(dw_mci_rockchip_runtime_suspend,
+ dw_mci_rockchip_runtime_resume,
+ NULL)
+};
+
static struct platform_driver dw_mci_rockchip_pltfm_driver = {
.probe = dw_mci_rockchip_probe,
- .remove = dw_mci_pltfm_remove,
+ .remove = dw_mci_rockchip_remove,
.driver = {
.name = "dwmmc_rockchip",
.of_match_table = dw_mci_rockchip_match,
- .pm = &dw_mci_pltfm_pmops,
+ .pm = &dw_mci_rockchip_dev_pm_ops,
},
};
--
2.3.7
^ permalink raw reply related
* [RFC PATCH v2 1/4] mmc: dw_mmc: add runtime PM callback
From: Shawn Lin @ 2016-09-30 8:48 UTC (permalink / raw)
To: Jaehoon Chung, Ulf Hansson
Cc: linux-mmc, Doug Anderson, linux-rockchip, Shawn Lin
In-Reply-To: <1475225317-2815-1-git-send-email-shawn.lin@rock-chips.com>
This patch add dw_mci_runtime_suspend/resume interfaces
and expose it to dw_mci variant driver to support runtime
PM.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
---
drivers/mmc/host/dw_mmc.c | 60 +++++++++++++++++++++++++++++++++++++++++++++--
drivers/mmc/host/dw_mmc.h | 4 +++-
2 files changed, 61 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 4fcbc40..54b860e 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -3266,7 +3266,7 @@ EXPORT_SYMBOL(dw_mci_remove);
-#ifdef CONFIG_PM_SLEEP
+#ifdef CONFIG_PM
/*
* TODO: we should probably disable the clock to the card in the suspend path.
*/
@@ -3324,7 +3324,63 @@ int dw_mci_resume(struct dw_mci *host)
return 0;
}
EXPORT_SYMBOL(dw_mci_resume);
-#endif /* CONFIG_PM_SLEEP */
+
+int dw_mci_runtime_suspend(struct dw_mci *host)
+{
+ printk("dw_mci_runtime_suspend\n");
+
+ if (host->use_dma && host->dma_ops->exit)
+ host->dma_ops->exit(host);
+
+ clk_disable_unprepare(host->ciu_clk);
+
+ return 0;
+}
+EXPORT_SYMBOL(dw_mci_runtime_suspend);
+
+int dw_mci_runtime_resume(struct dw_mci *host)
+{
+ int ret = 0;
+ int i;
+
+ printk("dw_mci_runtime_resume\n");
+
+ ret = clk_prepare_enable(host->ciu_clk);
+ if (ret)
+ return ret;
+
+ if (host->use_dma && host->dma_ops->init)
+ host->dma_ops->init(host);
+
+ mci_writel(host, FIFOTH, host->fifoth_val);
+ host->prev_blksz = 0;
+
+ mci_writel(host, TMOUT, 0xFFFFFFFF);
+ mci_writel(host, RINTSTS, 0xFFFFFFFF);
+ mci_writel(host, INTMASK, SDMMC_INT_CMD_DONE |
+ SDMMC_INT_DATA_OVER |
+ SDMMC_INT_TXDR | SDMMC_INT_RXDR |
+ DW_MCI_ERROR_FLAGS);
+ mci_writel(host, CTRL, SDMMC_CTRL_INT_ENABLE);
+
+ for (i = 0; i < host->num_slots; i++) {
+ struct dw_mci_slot *slot = host->slot[i];
+
+ if (!slot)
+ continue;
+
+ if (slot->mmc->pm_flags & MMC_PM_KEEP_POWER) {
+ dw_mci_set_ios(slot->mmc, &slot->mmc->ios);
+ dw_mci_setup_bus(slot, true);
+ }
+ }
+
+ dw_mci_enable_cd(host);
+
+ return ret;
+}
+EXPORT_SYMBOL(dw_mci_runtime_resume);
+#endif /* CONFIG_PM */
static int __init dw_mci_init(void)
{
diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
index e8cd2de..baa7261 100644
--- a/drivers/mmc/host/dw_mmc.h
+++ b/drivers/mmc/host/dw_mmc.h
@@ -234,9 +234,11 @@
extern int dw_mci_probe(struct dw_mci *host);
extern void dw_mci_remove(struct dw_mci *host);
-#ifdef CONFIG_PM_SLEEP
+#ifdef CONFIG_PM
extern int dw_mci_suspend(struct dw_mci *host);
extern int dw_mci_resume(struct dw_mci *host);
+extern int dw_mci_runtime_suspend(struct dw_mci *host);
+extern int dw_mci_runtime_resume(struct dw_mci *host);
#endif
/**
--
2.3.7
^ permalink raw reply related
* [RFC PATCH v2 0/4] Init runtime PM support for dw_mmc
From: Shawn Lin @ 2016-09-30 8:48 UTC (permalink / raw)
To: Jaehoon Chung, Ulf Hansson
Cc: linux-mmc, Doug Anderson, linux-rockchip, Shawn Lin
Hi Jaehoon and Ulf,
This a patchset going to support runtime PM for dw_mmc.
Basically it is a prototype design with some redundant
code there. But I think it's okay to send it out for sure
I am not heading in the wrong direction.
For v2, it could support to disable biu_clk and power-off genpd
if we find the gpio cd is used.
Shawn Lin (4):
mmc: dw_mmc: add runtime PM callback
mmc: dw_mmc-rockchip: add runtime PM support
mmc: core: expose the capability of gpio card detect
mmc: dw_mmc-rockchip: disable biu clk and genpd if possible
drivers/mmc/core/slot-gpio.c | 8 +++++
drivers/mmc/host/dw_mmc-rockchip.c | 73 ++++++++++++++++++++++++++++++++++++--
drivers/mmc/host/dw_mmc.c | 60 +++++++++++++++++++++++++++++--
drivers/mmc/host/dw_mmc.h | 4 ++-
include/linux/mmc/slot-gpio.h | 1 +
5 files changed, 140 insertions(+), 6 deletions(-)
--
2.3.7
^ permalink raw reply
* Re: [PATCH 2/2] mmc: sdhci-of-arasan: mark sdhci_arasan_reset() static
From: Sören Brinkmann @ 2016-09-30 6:30 UTC (permalink / raw)
To: Baoyou Xie
Cc: michal.simek, adrian.hunter, ulf.hansson, linux-arm-kernel,
linux-mmc, linux-kernel, arnd, xie.baoyou, han.fei, tang.qiang007
In-Reply-To: <1475199459-4775-2-git-send-email-baoyou.xie@linaro.org>
On Fri, 2016-09-30 at 09:37:39 +0800, Baoyou Xie wrote:
> We get 1 warning when building kernel with W=1:
> drivers/mmc/host/sdhci-of-arasan.c:253:6: warning: no previous prototype for 'sdhci_arasan_reset' [-Wmissing-prototypes]
>
> In fact, this function is only used in the file in which it is
> declared and don't need a declaration, but can be made static.
> So this patch marks it 'static'.
>
> Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
There is already a patch for this:
https://patchwork.kernel.org/patch/9349805/
Sören
^ permalink raw reply
* [PATCH v3 3/3] mmc: sdhci-of-arasan: add sdhci_arasan_voltage_switch for arasan,5.1
From: Shawn Lin @ 2016-09-30 6:19 UTC (permalink / raw)
To: Ulf Hansson
Cc: Adrian Hunter, linux-mmc, Doug Anderson, Ziyuan Xu,
linux-rockchip, Shawn Lin
In-Reply-To: <1475216340-15344-1-git-send-email-shawn.lin@rock-chips.com>
Per the vendor's requirement, we shouldn't do any setting for
1.8V Signaling Enable, otherwise the interaction/behaviour between
phy and controller will be undefined. Mostly it works fine if we do
that, but we still see failures. Anyway, let's fix it to meet the
vendor's requirement. The error log looks like:
[ 93.405085] mmc1: unexpected status 0x800900 after switch
[ 93.408474] mmc1: switch to bus width 1 failed
[ 93.408482] mmc1: mmc_select_hs200 failed, error -110
[ 93.408492] mmc1: error -110 during resume (card was removed?)
[ 93.408705] PM: resume of devices complete after 213.453 msecs
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
---
Changes in v3:
- add tag from Adrian and Doug
Changes in v2: None
drivers/mmc/host/sdhci-of-arasan.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
index da8e40a..1573a8d 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -265,6 +265,28 @@ void sdhci_arasan_reset(struct sdhci_host *host, u8 mask)
}
}
+static int sdhci_arasan_voltage_switch(struct mmc_host *mmc,
+ struct mmc_ios *ios)
+{
+ switch (ios->signal_voltage) {
+ case MMC_SIGNAL_VOLTAGE_180:
+ /*
+ * Plese don't switch to 1V8 as arasan,5.1 doesn't
+ * actually refer to this setting to indicate the
+ * signal voltage and the state machine will be broken
+ * actually if we force to enable 1V8. That's something
+ * like broken quirk but we could work around here.
+ */
+ return 0;
+ case MMC_SIGNAL_VOLTAGE_330:
+ case MMC_SIGNAL_VOLTAGE_120:
+ /* We don't support 3V3 and 1V2 */
+ break;
+ }
+
+ return -EINVAL;
+}
+
static struct sdhci_ops sdhci_arasan_ops = {
.set_clock = sdhci_arasan_set_clock,
.get_max_clock = sdhci_pltfm_clk_get_max_clock,
@@ -661,6 +683,8 @@ static int sdhci_arasan_probe(struct platform_device *pdev)
host->mmc_host_ops.hs400_enhanced_strobe =
sdhci_arasan_hs400_enhanced_strobe;
+ host->mmc_host_ops.start_signal_voltage_switch =
+ sdhci_arasan_voltage_switch;
}
ret = sdhci_add_host(host);
--
2.3.7
^ permalink raw reply related
* [PATCH v3 2/3] mmc: core: changes frequency to hs_max_dtr when selecting hs400es
From: Shawn Lin @ 2016-09-30 6:18 UTC (permalink / raw)
To: Ulf Hansson
Cc: Adrian Hunter, linux-mmc, Doug Anderson, Ziyuan Xu,
linux-rockchip, Shawn Lin
In-Reply-To: <1475216340-15344-1-git-send-email-shawn.lin@rock-chips.com>
Per JESD84-B51 P49, Host need to change frequency to <=52MHz
after setting HS_TIMING to 0x1, and host may changes frequency
to <= 200MHz after setting HS_TIMING to 0x3. That means the card
expects the clock rate to increase from the current used f_init
(which is less than 400KHz, but still being less than 52MHz) to
52MHz, otherwise we find some eMMC devices significantly report
failure when sending status.
Reported-by: Xiao Yao <xiaoyao@rock-chips.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
---
Changes in v3:
- add Doug's tag and fix the wrong page index of spec
Changes in v2:
- improve the changelog
drivers/mmc/core/mmc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index f4ed5ac..39fc5b2 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1282,6 +1282,8 @@ static int mmc_select_hs400es(struct mmc_card *card)
if (err)
goto out_err;
+ mmc_set_clock(host, card->ext_csd.hs_max_dtr);
+
err = mmc_switch_status(card);
if (err)
goto out_err;
--
2.3.7
^ permalink raw reply related
* [PATCH v3 1/3] mmc: core: switch to 1V8 or 1V2 for hs400es mode
From: Shawn Lin @ 2016-09-30 6:18 UTC (permalink / raw)
To: Ulf Hansson
Cc: Adrian Hunter, linux-mmc, Doug Anderson, Ziyuan Xu,
linux-rockchip, Shawn Lin, stable
When introducing hs400es, I didn't notice that we haven't
switched voltage to 1V2 or 1V8 for it. That happens to work
as the first controller claiming to support hs400es, arasan(5.1),
which is designed to only support 1V8. So the voltage is fixed to 1V8.
But it actually is wrong, and will not fit for other host controllers.
Let's fix it.
Fixes: commit 81ac2af65793ecf ("mmc: core: implement enhanced strobe support")
Cc: <stable@vger.kernel.org>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
---
Changes in v3:
- add Doug's tag
Changes in v2:
- fix copy-paste error, mea culpa
drivers/mmc/core/mmc.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 3486bc7..f4ed5ac 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1263,6 +1263,16 @@ static int mmc_select_hs400es(struct mmc_card *card)
goto out_err;
}
+ if (card->mmc_avail_type & EXT_CSD_CARD_TYPE_HS400_1_2V)
+ err = __mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_120);
+
+ if (err && card->mmc_avail_type & EXT_CSD_CARD_TYPE_HS400_1_8V)
+ err = __mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_180);
+
+ /* If fails try again during next card power cycle */
+ if (err)
+ goto out_err;
+
err = mmc_select_bus_width(card);
if (err < 0)
goto out_err;
--
2.3.7
^ permalink raw reply related
* [PATCH 2/2] mmc: sdhci-of-arasan: mark sdhci_arasan_reset() static
From: Baoyou Xie @ 2016-09-30 1:37 UTC (permalink / raw)
To: michal.simek, soren.brinkmann, adrian.hunter, ulf.hansson,
linux-arm-kernel
Cc: linux-mmc, linux-kernel, arnd, baoyou.xie, xie.baoyou, han.fei,
tang.qiang007
In-Reply-To: <1475199459-4775-1-git-send-email-baoyou.xie@linaro.org>
We get 1 warning when building kernel with W=1:
drivers/mmc/host/sdhci-of-arasan.c:253:6: warning: no previous prototype for 'sdhci_arasan_reset' [-Wmissing-prototypes]
In fact, this function is only used in the file in which it is
declared and don't need a declaration, but can be made static.
So this patch marks it 'static'.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
drivers/mmc/host/sdhci-of-arasan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
index da8e40a..e263671 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -250,7 +250,7 @@ static void sdhci_arasan_hs400_enhanced_strobe(struct mmc_host *mmc,
writel(vendor, host->ioaddr + SDHCI_ARASAN_VENDOR_REGISTER);
}
-void sdhci_arasan_reset(struct sdhci_host *host, u8 mask)
+static void sdhci_arasan_reset(struct sdhci_host *host, u8 mask)
{
u8 ctrl;
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] mmc: block: add missing header dependencies
From: Baoyou Xie @ 2016-09-30 1:37 UTC (permalink / raw)
To: michal.simek, soren.brinkmann, adrian.hunter, ulf.hansson,
linux-arm-kernel
Cc: linux-mmc, linux-kernel, arnd, baoyou.xie, xie.baoyou, han.fei,
tang.qiang007
We get 1 warning when building kernel with W=1:
drivers/mmc/card/block.c:2147:5: warning: no previous prototype for 'mmc_blk_issue_rq' [-Wmissing-prototypes]
In fact, this function is declared in drivers/mmc/card/block.h,
so this patch adds missing header dependencies.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
drivers/mmc/card/block.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index c333511..0f2cc9f2 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -46,6 +46,7 @@
#include <asm/uaccess.h>
#include "queue.h"
+#include "block.h"
MODULE_ALIAS("mmc:block");
#ifdef MODULE_PARAM_PREFIX
--
2.7.4
^ permalink raw reply related
* Re: [PATCH PoC 0/7] mmc: switch to blk-mq
From: Linus Walleij @ 2016-09-30 0:50 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Ulf Hansson, Greg KH, Paolo Valente, Jens Axboe, Hannes Reinecke,
Tejun Heo, Omar Sandoval, Christoph Hellwig,
linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org,
Arnd Bergmann
In-Reply-To: <1474552630-28314-1-git-send-email-b.zolnierkie@samsung.com>
On Thu, Sep 22, 2016 at 6:57 AM, Bartlomiej Zolnierkiewicz
<b.zolnierkie@samsung.com> wrote:
> Since Linus Walleij is also working on that and I won't
> probably have time to touch this code till the end of
> upcoming month, here it is (basically a code dump of my
> proof-of-concept work). I hope that it would be useful
> to somebody.
>
> It is extremely ugly & full of bogus debug code but boots
> fine on my Odroid-XU3 and benchmarks can be run.
Haha, it is still good discussion material.
FWIW your patchset is way more advanced than whatever I
cooked up, and the approach taken: first rip out async requests,
then adding a mq callback block and add async requests back
after adding a function to monitor if the queue is busy is a way
better approach.
I sat down with Ulf Hansson and Arnd Bergmann to discuss the
material and issues we face if/when migrating the MMC/SD code
to blk-mq.
Just for context to everyone: MMC/SD has an asynchronous
request handling that achieves a call all the way into the driver
to do some DMA mapping (flush) of SGlists with dma_map_sg()
before the hardware start processing the actual request. There
is a post_req() callback as well performing dma_unmap_sg().
This is mostly a non-issue on coherent memory architectures
like x86, but gives a nice performance boost on ARM (etc)
systems. In theory the callback could be used for other stuff
but all current drivers ultimately call
dma_map_sg()/dma_unmap_sg().
The interesting solution to achieve asynchronous requests,
a.k.a. double-buffering a.k.a. request pipelining is basically this
from the last patch:
- mq->qdepth = 1;
+ mq->qdepth = 2;
So we claim that the hardware queue has a depth of two
requests but well... that is not really true. If we start confusing
concepts like this to get parallelism, what shall we set this
to when we exploit command queueing and actually have a
queue depth of say 64? that will result in a pile of hacks.
The proper solution would be to augment struct blk_mq_ops
vtable with a .pre_queue_rq() and .post_complete_rq() or
something.
The way I read the code the init_request() and exit_request()
callbacks cannot be used as they only deal with allocating the
struct and this seems to happen before the request is actually
filled in with the data (correct me if I don't understand this right!)
this seems to be confirmed by the presence of a .reinit_request()
callback. So we can't map/unmap the requests in these
callbacks.
We noted that this dma map/upmap optimization can also be
applicable for USB mass storage, so we get an optimization
from the MQ block layer that we can reuse in more than
MMC/SD.
After this we will still run into the same issue that you find after
this patchset: regressions in performance because of the
absence of an elevator/scheduler algorithm in blk-mq. So we
cannot really apply the patch set before or at the same time
as we're fixing that.
Apart from that we saw some really arcane things in the
MMC/SD core, mmc_claim_host() being the most obvious
example, as far as we can tell some kind of reimplementation of
mutex_trylock(). Some serious cleanup may be needed here.
It's nice that your first patch rips out the quirky kthread that
polls the block queue for new requests and send them down
to the mmc core, including picking out a few NULL requests
and flusing it's asynch work queue with that.
Yours,
Linus Walleij
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox