We've already got a reset of DMA after it's done. Add one before we
start DMA too. This fixes a data corruption on Rockchip SoCs which
will get bad data when doing a DMA transfer after doing a PIO transfer.
We tested this on an Exynos 5800 with HS200 and didn't notice any
difference in sequential read throughput.
Signed-off-by: Sonny Rao <[email protected]>
Signed-off-by: Doug Anderson <[email protected]>
---
drivers/mmc/host/dw_mmc.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 69f0cc6..2b5401e 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -83,6 +83,7 @@ struct idmac_desc {
#endif /* CONFIG_MMC_DW_IDMAC */
static bool dw_mci_reset(struct dw_mci *host);
+static bool dw_mci_ctrl_reset(struct dw_mci *host, u32 reset);
#if defined(CONFIG_DEBUG_FS)
static int dw_mci_req_show(struct seq_file *s, void *v)
@@ -448,6 +449,9 @@ static void dw_mci_idmac_start_dma(struct dw_mci *host, unsigned int sg_len)
dw_mci_translate_sglist(host, host->data, sg_len);
+ /* Make sure to reset DMA in case we did PIO before this */
+ dw_mci_ctrl_reset(host, SDMMC_CTRL_DMA_RESET);
+
/* Select IDMAC interface */
temp = mci_readl(host, CTRL);
temp |= SDMMC_CTRL_USE_IDMAC;
--
1.8.3.2
Sonny,
On Mon, Oct 6, 2014 at 10:53 AM, Sonny Rao <[email protected]> wrote:
> We've already got a reset of DMA after it's done. Add one before we
> start DMA too. This fixes a data corruption on Rockchip SoCs which
> will get bad data when doing a DMA transfer after doing a PIO transfer.
>
> We tested this on an Exynos 5800 with HS200 and didn't notice any
> difference in sequential read throughput.
>
> Signed-off-by: Sonny Rao <[email protected]>
> Signed-off-by: Doug Anderson <[email protected]>
> ---
> drivers/mmc/host/dw_mmc.c | 4 ++++
> 1 file changed, 4 insertions(+)
Reviewed-by: Doug Anderson <[email protected]>
Tested-by: Doug Anderson <[email protected]>
Acked-by: Jaehoon Chung <[email protected]>
On 10/07/2014 03:11 AM, Doug Anderson wrote:
> Sonny,
>
> On Mon, Oct 6, 2014 at 10:53 AM, Sonny Rao <[email protected]> wrote:
>> We've already got a reset of DMA after it's done. Add one before we
>> start DMA too. This fixes a data corruption on Rockchip SoCs which
>> will get bad data when doing a DMA transfer after doing a PIO transfer.
>>
>> We tested this on an Exynos 5800 with HS200 and didn't notice any
>> difference in sequential read throughput.
>>
>> Signed-off-by: Sonny Rao <[email protected]>
>> Signed-off-by: Doug Anderson <[email protected]>
>> ---
>> drivers/mmc/host/dw_mmc.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>
> Reviewed-by: Doug Anderson <[email protected]>
> Tested-by: Doug Anderson <[email protected]>
>
Hi Sonny/Doug,
On Mon, Oct 6, 2014 at 11:23 PM, Sonny Rao <[email protected]> wrote:
> We've already got a reset of DMA after it's done. Add one before we
> start DMA too. This fixes a data corruption on Rockchip SoCs which
> will get bad data when doing a DMA transfer after doing a PIO transfer.
>
> We tested this on an Exynos 5800 with HS200 and didn't notice any
> difference in sequential read throughput.
>
> Signed-off-by: Sonny Rao <[email protected]>
> Signed-off-by: Doug Anderson <[email protected]>
> ---
> drivers/mmc/host/dw_mmc.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index 69f0cc6..2b5401e 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -83,6 +83,7 @@ struct idmac_desc {
> #endif /* CONFIG_MMC_DW_IDMAC */
>
> static bool dw_mci_reset(struct dw_mci *host);
> +static bool dw_mci_ctrl_reset(struct dw_mci *host, u32 reset);
>
> #if defined(CONFIG_DEBUG_FS)
> static int dw_mci_req_show(struct seq_file *s, void *v)
> @@ -448,6 +449,9 @@ static void dw_mci_idmac_start_dma(struct dw_mci *host, unsigned int sg_len)
>
> dw_mci_translate_sglist(host, host->data, sg_len);
>
> + /* Make sure to reset DMA in case we did PIO before this */
> + dw_mci_ctrl_reset(host, SDMMC_CTRL_DMA_RESET);
> +
Though this is good to do, but this does not look complete to me.
dw_mmc data book does mention that " It is recommended that the host
issue reset to DMA interface by setting DMA_RESET bit of the CTRL
register and then issue a IDMAC software reset."
The above lines are from 'Transmission and reception with internal
DMA' section of the data book.
My suggestion here to add dw_mci_idmac_reset() call after this above change.
What is the controller version used in your case?
> /* Select IDMAC interface */
> temp = mci_readl(host, CTRL);
> temp |= SDMMC_CTRL_USE_IDMAC;
> --
> 1.8.3.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Regards,
Alim
Hi Eddie,
On Thu, Oct 9, 2014 at 7:43 PM, Eddie Cai(蔡枫) <[email protected]> wrote:
> Hi Alim
>
> 2014年10月8日 上午4:28于 "Alim Akhtar" <[email protected]>写道：
>
>
>>
>> Hi Sonny/Doug,
>>
>> On Mon, Oct 6, 2014 at 11:23 PM, Sonny Rao <[email protected]> wrote:
>> > We've already got a reset of DMA after it's done. Add one before we
>> > start DMA too. This fixes a data corruption on Rockchip SoCs which
>> > will get bad data when doing a DMA transfer after doing a PIO transfer.
>> >
>> > We tested this on an Exynos 5800 with HS200 and didn't notice any
>> > difference in sequential read throughput.
>> >
>> > Signed-off-by: Sonny Rao <[email protected]>
>> > Signed-off-by: Doug Anderson <[email protected]>
>> > ---
>> > drivers/mmc/host/dw_mmc.c | 4 ++++
>> > 1 file changed, 4 insertions(+)
>> >
>> > diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> > index 69f0cc6..2b5401e 100644
>> > --- a/drivers/mmc/host/dw_mmc.c
>> > +++ b/drivers/mmc/host/dw_mmc.c
>> > @@ -83,6 +83,7 @@ struct idmac_desc {
>> > #endif /* CONFIG_MMC_DW_IDMAC */
>> >
>> > static bool dw_mci_reset(struct dw_mci *host);
>> > +static bool dw_mci_ctrl_reset(struct dw_mci *host, u32 reset);
>> >
>> > #if defined(CONFIG_DEBUG_FS)
>> > static int dw_mci_req_show(struct seq_file *s, void *v)
>> > @@ -448,6 +449,9 @@ static void dw_mci_idmac_start_dma(struct dw_mci
>> > *host, unsigned int sg_len)
>> >
>> > dw_mci_translate_sglist(host, host->data, sg_len);
>> >
>> > + /* Make sure to reset DMA in case we did PIO before this */
>> > + dw_mci_ctrl_reset(host, SDMMC_CTRL_DMA_RESET);
>> > +
>> Though this is good to do, but this does not look complete to me.
>> dw_mmc data book does mention that " It is recommended that the host
>> issue reset to DMA interface by setting DMA_RESET bit of the CTRL
>> register and then issue a IDMAC software reset."
>> The above lines are from 'Transmission and reception with internal
>> DMA' section of the data book.
>> My suggestion here to add dw_mci_idmac_reset() call after this above
>> change.
>>
>> What is the controller version used in your case?
>
> it just compatible with dw mmc controler but not the same one. it is
> designed by rockchip.
>
Thats fine, I think every vendor (most of them) has a custom
implementation of dw_mmc, but they do have VERID register to check the
dw_mmc version.
The reason why I asked is, I have seen inconsistency in card
enumeration on few controller version, and this patch alone does not
help, and adding a call to dw_mci_idmac_reset() after DMA reset is
needed. And this is what is recommended in the synopsys's data book
also.
Do you see any issue/side effect after adding dw_mci_idmac_reset()?
>> > /* Select IDMAC interface */
>> > temp = mci_readl(host, CTRL);
>> > temp |= SDMMC_CTRL_USE_IDMAC;
>> > --
>> > 1.8.3.2
>> >
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>> > the body of a message to [email protected]
>> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
>>
>> --
>> Regards,
>> Alim
>>
>>
--
Regards,
Alim
Alim,
On Thu, Oct 9, 2014 at 3:19 PM, Alim Akhtar <[email protected]> wrote:
> Thats fine, I think every vendor (most of them) has a custom
> implementation of dw_mmc, but they do have VERID register to check the
> dw_mmc version.
> The reason why I asked is, I have seen inconsistency in card
> enumeration on few controller version, and this patch alone does not
> help, and adding a call to dw_mci_idmac_reset() after DMA reset is
> needed. And this is what is recommended in the synopsys's data book
> also.
> Do you see any issue/side effect after adding dw_mci_idmac_reset()?
A quick test shows no problem with adding this to Sonny's patch:
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 66dc8fe..588b5b8 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -481,6 +481,7 @@ static void dw_mci_idmac_start_dma(struct dw_mci
*host, unsigned int sg_len)
/* Make sure to reset DMA in case we did PIO before this */
dw_mci_ctrl_reset(host, SDMMC_CTRL_DMA_RESET);
+ dw_mci_idmac_reset(host);
/* Select IDMAC interface */
temp = mci_readl(host, CTRL);
I'll start reboot tests now to see how it behaves... I think Sonny is
out of the office for a few days so we might need to wait for a spin,
but I'll run with that change in the meantime and see how it behaves
for me.
Thanks!
-Doug
Hi,
On Thu, Oct 9, 2014 at 5:36 PM, Doug Anderson <[email protected]> wrote:
> Alim,
>
> On Thu, Oct 9, 2014 at 3:19 PM, Alim Akhtar <[email protected]> wrote:
>> Thats fine, I think every vendor (most of them) has a custom
>> implementation of dw_mmc, but they do have VERID register to check the
>> dw_mmc version.
>> The reason why I asked is, I have seen inconsistency in card
>> enumeration on few controller version, and this patch alone does not
>> help, and adding a call to dw_mci_idmac_reset() after DMA reset is
>> needed. And this is what is recommended in the synopsys's data book
>> also.
>> Do you see any issue/side effect after adding dw_mci_idmac_reset()?
>
> A quick test shows no problem with adding this to Sonny's patch:
>
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index 66dc8fe..588b5b8 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -481,6 +481,7 @@ static void dw_mci_idmac_start_dma(struct dw_mci
> *host, unsigned int sg_len)
>
> /* Make sure to reset DMA in case we did PIO before this */
> dw_mci_ctrl_reset(host, SDMMC_CTRL_DMA_RESET);
> + dw_mci_idmac_reset(host);
>
> /* Select IDMAC interface */
> temp = mci_readl(host, CTRL);
>
> I'll start reboot tests now to see how it behaves... I think Sonny is
> out of the office for a few days so we might need to wait for a spin,
> but I'll run with that change in the meantime and see how it behaves
> for me.
>
> Thanks!
Just FYI that I've been running with Alim's proposed change for
several days and it seems solid. I think Sonny may be able to spin
his patch this week. :)
-Doug
Hi Doug,
On Tue, Oct 14, 2014 at 10:21 PM, Doug Anderson <[email protected]> wrote:
> Hi,
>
> On Thu, Oct 9, 2014 at 5:36 PM, Doug Anderson <[email protected]> wrote:
>> Alim,
>>
>> On Thu, Oct 9, 2014 at 3:19 PM, Alim Akhtar <[email protected]> wrote:
>>> Thats fine, I think every vendor (most of them) has a custom
>>> implementation of dw_mmc, but they do have VERID register to check the
>>> dw_mmc version.
>>> The reason why I asked is, I have seen inconsistency in card
>>> enumeration on few controller version, and this patch alone does not
>>> help, and adding a call to dw_mci_idmac_reset() after DMA reset is
>>> needed. And this is what is recommended in the synopsys's data book
>>> also.
>>> Do you see any issue/side effect after adding dw_mci_idmac_reset()?
>>
>> A quick test shows no problem with adding this to Sonny's patch:
>>
>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> index 66dc8fe..588b5b8 100644
>> --- a/drivers/mmc/host/dw_mmc.c
>> +++ b/drivers/mmc/host/dw_mmc.c
>> @@ -481,6 +481,7 @@ static void dw_mci_idmac_start_dma(struct dw_mci
>> *host, unsigned int sg_len)
>>
>> /* Make sure to reset DMA in case we did PIO before this */
>> dw_mci_ctrl_reset(host, SDMMC_CTRL_DMA_RESET);
>> + dw_mci_idmac_reset(host);
>>
>> /* Select IDMAC interface */
>> temp = mci_readl(host, CTRL);
>>
>> I'll start reboot tests now to see how it behaves... I think Sonny is
>> out of the office for a few days so we might need to wait for a spin,
>> but I'll run with that change in the meantime and see how it behaves
>> for me.
>>
>> Thanks!
>
> Just FYI that I've been running with Alim's proposed change for
> several days and it seems solid. I think Sonny may be able to spin
> his patch this week. :)
>
Sounds great. Thanks for testing.
> -Doug
--
Regards,
Alim