| Message ID | 201305212307.55385.sergei.shtylyov@cogentembedded.com |
|---|---|
| State | Not Applicable |
| Delegated to: | David Miller |
| Headers | show |
On Tue, May 21, 2013 at 11:07:54PM +0400, Sergei Shtylyov wrote: > Iff bmdma_setup() has to stop a DMA transfer before starting a new one, then the > STOP bit in the ATAPI_CONTROL1 register will remain set (it's only cleared when > setting the START bit to 1) and then bmdma_start() method will set both START > and STOP bits simultaneously which should abort the transfer being just started. > Avoid that by explicitly clearing the STOP bit in bmdma_start() method (in this > case it will be ignored on write). > > Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Applied to libata/for-3.10-fixes w/ stable cc'd. Thanks.
Hello. On 22-05-2013 3:41, Tejun Heo wrote: >> Iff bmdma_setup() has to stop a DMA transfer before starting a new one, then the >> STOP bit in the ATAPI_CONTROL1 register will remain set (it's only cleared when >> setting the START bit to 1) and then bmdma_start() method will set both START >> and STOP bits simultaneously which should abort the transfer being just started. >> Avoid that by explicitly clearing the STOP bit in bmdma_start() method (in this >> case it will be ignored on write). >> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> > Applied to libata/for-3.10-fixes w/ stable cc'd. Thanks, I forgot about -stable. Anyway, it doesn't seem that serious as bmdma_setup() usually shouldn't abort DMA. > Thanks. WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello. On 22-05-2013 17:12, Sergei Shtylyov wrote: >>> Iff bmdma_setup() has to stop a DMA transfer before starting a new >>> one, then the >>> STOP bit in the ATAPI_CONTROL1 register will remain set (it's only >>> cleared when >>> setting the START bit to 1) and then bmdma_start() method will set >>> both START >>> and STOP bits simultaneously which should abort the transfer being >>> just started. >>> Avoid that by explicitly clearing the STOP bit in bmdma_start() >>> method (in this >>> case it will be ignored on write). >>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> >> Applied to libata/for-3.10-fixes w/ stable cc'd. > Thanks, I forgot about -stable. Anyway, it doesn't seem that serious > as bmdma_setup() usually shouldn't abort DMA. Although bmdma_stop() also can stop DMA which is not as improbable (media errors, etc.). I could have wrotten a better changelog. :-/ >> Thanks. WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Index: libata/drivers/ata/sata_rcar.c =================================================================== --- libata.orig/drivers/ata/sata_rcar.c +++ libata/drivers/ata/sata_rcar.c @@ -549,6 +549,7 @@ static void sata_rcar_bmdma_start(struct /* start host DMA transaction */ dmactl = ioread32(priv->base + ATAPI_CONTROL1_REG); + dmactl &= ~ATAPI_CONTROL1_STOP; dmactl |= ATAPI_CONTROL1_START; iowrite32(dmactl, priv->base + ATAPI_CONTROL1_REG); }
Iff bmdma_setup() has to stop a DMA transfer before starting a new one, then the STOP bit in the ATAPI_CONTROL1 register will remain set (it's only cleared when setting the START bit to 1) and then bmdma_start() method will set both START and STOP bits simultaneously which should abort the transfer being just started. Avoid that by explicitly clearing the STOP bit in bmdma_start() method (in this case it will be ignored on write). Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> --- This patch is against 'for-3.10-fixes' branch of Tejun Heo's 'libata.git' repo. drivers/ata/sata_rcar.c | 1 + 1 file changed, 1 insertion(+) -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html