| Message ID | 20191230092343.30692-1-faiz_abbas@ti.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Fix issues with command queuing in arasan controllers | expand |
Hi, On 30/12/19 2:53 pm, Faiz Abbas wrote: > In some Arasan SDHCI controllers, after tuning, the tuning pattern data > is leftover in the sdhci buffer. This leads to issues with future data > commands, especially when command queuing is enabled. The following > patches help fix this issue by resetting data lines after tuning is > finished. The first two patches have been tested with TI's am65x and > j721e SoCs using the sdhci_am654 driver. > > I have a strong suspicion that this is the same issue with > the sdhci-of-arasan driver where they are forced to dump data from the > buffer before enabling command queuing. I need help from someone with a > compatible platform to test this. > I had some discussions with our hardware team and they say we should be asserting both SRC and SRD reset after tuning to start from a clean state. Will update the patches to do that in v2. Thanks, Faiz
On 8/01/20 1:30 pm, Faiz Abbas wrote: > Hi, > > On 30/12/19 2:53 pm, Faiz Abbas wrote: >> In some Arasan SDHCI controllers, after tuning, the tuning pattern data >> is leftover in the sdhci buffer. This leads to issues with future data >> commands, especially when command queuing is enabled. The following >> patches help fix this issue by resetting data lines after tuning is >> finished. The first two patches have been tested with TI's am65x and >> j721e SoCs using the sdhci_am654 driver. >> >> I have a strong suspicion that this is the same issue with >> the sdhci-of-arasan driver where they are forced to dump data from the >> buffer before enabling command queuing. I need help from someone with a >> compatible platform to test this. >> > > I had some discussions with our hardware team and they say we should be > asserting both SRC and SRD reset after tuning to start from a clean > state. Will update the patches to do that in v2. Can you use the ->execute_tuning() for that instead of a quirk?
Adrian, On 08/01/20 5:12 pm, Adrian Hunter wrote: > On 8/01/20 1:30 pm, Faiz Abbas wrote: >> Hi, >> >> On 30/12/19 2:53 pm, Faiz Abbas wrote: >>> In some Arasan SDHCI controllers, after tuning, the tuning pattern data >>> is leftover in the sdhci buffer. This leads to issues with future data >>> commands, especially when command queuing is enabled. The following >>> patches help fix this issue by resetting data lines after tuning is >>> finished. The first two patches have been tested with TI's am65x and >>> j721e SoCs using the sdhci_am654 driver. >>> >>> I have a strong suspicion that this is the same issue with >>> the sdhci-of-arasan driver where they are forced to dump data from the >>> buffer before enabling command queuing. I need help from someone with a >>> compatible platform to test this. >>> >> >> I had some discussions with our hardware team and they say we should be >> asserting both SRC and SRD reset after tuning to start from a clean >> state. Will update the patches to do that in v2. > > Can you use the ->execute_tuning() for that instead of a quirk? > ->platform_execute_tuning() is called before __sdhci_execute_tuning(). I need this to be done after that. Should I add a post_tuning() callback? Thanks, Faiz
On 8/01/20 1:49 pm, Faiz Abbas wrote: > Adrian, > > On 08/01/20 5:12 pm, Adrian Hunter wrote: >> On 8/01/20 1:30 pm, Faiz Abbas wrote: >>> Hi, >>> >>> On 30/12/19 2:53 pm, Faiz Abbas wrote: >>>> In some Arasan SDHCI controllers, after tuning, the tuning pattern data >>>> is leftover in the sdhci buffer. This leads to issues with future data >>>> commands, especially when command queuing is enabled. The following >>>> patches help fix this issue by resetting data lines after tuning is >>>> finished. The first two patches have been tested with TI's am65x and >>>> j721e SoCs using the sdhci_am654 driver. >>>> >>>> I have a strong suspicion that this is the same issue with >>>> the sdhci-of-arasan driver where they are forced to dump data from the >>>> buffer before enabling command queuing. I need help from someone with a >>>> compatible platform to test this. >>>> >>> >>> I had some discussions with our hardware team and they say we should be >>> asserting both SRC and SRD reset after tuning to start from a clean >>> state. Will update the patches to do that in v2. >> >> Can you use the ->execute_tuning() for that instead of a quirk? >> > > ->platform_execute_tuning() is called before __sdhci_execute_tuning(). I > need this to be done after that. Should I add a post_tuning() callback? I meant hook host->mmc_host_ops.execute_tuning and call sdhci_execute_tuning() and then sdhci_reset(), like in intel_execute_tuning().
Hi Adrian, On 08/01/20 5:29 pm, Adrian Hunter wrote: > On 8/01/20 1:49 pm, Faiz Abbas wrote: >> Adrian, >> >> On 08/01/20 5:12 pm, Adrian Hunter wrote: >>> On 8/01/20 1:30 pm, Faiz Abbas wrote: >>>> Hi, >>>> >>>> On 30/12/19 2:53 pm, Faiz Abbas wrote: >>>>> In some Arasan SDHCI controllers, after tuning, the tuning pattern data >>>>> is leftover in the sdhci buffer. This leads to issues with future data >>>>> commands, especially when command queuing is enabled. The following >>>>> patches help fix this issue by resetting data lines after tuning is >>>>> finished. The first two patches have been tested with TI's am65x and >>>>> j721e SoCs using the sdhci_am654 driver. >>>>> >>>>> I have a strong suspicion that this is the same issue with >>>>> the sdhci-of-arasan driver where they are forced to dump data from the >>>>> buffer before enabling command queuing. I need help from someone with a >>>>> compatible platform to test this. >>>>> >>>> >>>> I had some discussions with our hardware team and they say we should be >>>> asserting both SRC and SRD reset after tuning to start from a clean >>>> state. Will update the patches to do that in v2. >>> >>> Can you use the ->execute_tuning() for that instead of a quirk? >>> >> >> ->platform_execute_tuning() is called before __sdhci_execute_tuning(). I >> need this to be done after that. Should I add a post_tuning() callback? > > I meant hook host->mmc_host_ops.execute_tuning and call > sdhci_execute_tuning() and then sdhci_reset(), like in intel_execute_tuning(). > Ok. Makes sense. Thanks, Faiz