Path: csiph.com!news.mixmin.net!news.unit0.net!news.panservice.it!bofh.it!news.nic.it!robomod
From: Yao Yuan <yao.yuan@nxp.com>
Newsgroups: linux.kernel
Subject: RE: [PATCH v1 1/5] dma: Add QorIQ qDMA engine driver support
Date: Wed, 24 Aug 2016 09:20:02 +0200
Message-ID: <s9ADE-7nn-11@gated-at.bofh.it>
References: <s7rEt-6bL-5@gated-at.bofh.it> <s7rEt-6bL-7@gated-at.bofh.it> <s7rEt-6bL-3@gated-at.bofh.it>
Thread-Topic: [PATCH v1 1/5] dma: Add QorIQ qDMA engine driver support
Thread-Index: AQHR+RzOuyl5MDQIvkeDE5tT439/VqBOcA+AgAkDdyA=
Accept-Language: en-US, zh-CN
Content-Language: en-US
Received-Spf: None (protection.outlook.com: nxp.com does not designate permitted sender hosts)
Spamdiagnosticoutput: 1:99
Spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Ms-Exchange-Crosstenant-Originalarrivaltime: 24 Aug 2016 03:39:11.8878 (UTC)
X-Ms-Exchange-Crosstenant-Fromentityheader: Hosted
X-Ms-Exchange-Crosstenant-ID: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-Ms-Exchange-Transport-Crosstenantheadersstamped: DB6PR0401MB2408
Sender: robomod@news.nic.it
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Approved: robomod@news.nic.it
Lines: 29
Organization: linux.* mail to news gateway
X-Original-Cc: "vinod.koul@intel.com" <vinod.koul@intel.com>, "robh+dt@kernel.org" <robh+dt@kernel.org>, "dan.j.williams@intel.com" <dan.j.williams@intel.com>, "mark.rutland@arm.com" <mark.rutland@arm.com>, "shawnguo@kernel.org" <shawnguo@kernel.org>, Yang-Leo Li <leoyang.li@nxp.com>, "dmaengine@vger.kernel.org" <dmaengine@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>
X-Original-Date: Wed, 24 Aug 2016 03:39:11 +0000
X-Original-Message-ID: <DB6PR0401MB240759E8AC4DEB23EBC1159389EA0@DB6PR0401MB2407.eurprd04.prod.outlook.com>
X-Original-References: <1471502328-28305-1-git-send-email-yao.yuan@freescale.com> <1471502328-28305-2-git-send-email-yao.yuan@freescale.com> <20160818091603.GT1041@n2100.armlinux.org.uk>
X-Original-Sender: linux-kernel-owner@vger.kernel.org
Xref: csiph.com linux.kernel:1469128

On Thu, Aug 18, 2016 at 05:16 PM +0800, Russell King wrote:
> On Thu, Aug 18, 2016 at 02:38:44PM +0800, Yuan Yao wrote:
> > +			spin_lock(&fsl_comp->qchan->vchan.lock);
> > +			if (status =3D=3D DMA_COMPLETE)
> > +				vchan_cookie_complete(&fsl_comp->vdesc);
> > +			fsl_comp->qchan->status =3D status;
>=20
> This is buggy - if the DMA has finished processing it, even if it finishe=
d in error, it
> must _complete_ the transaction.  Completion is not the same as being
> successful - it means that the DMA is no longer processing the cookie.
>=20
> The issue here is that when the _following_ transaction completes success=
fully,
> _this_ transaction will effectively be marked as complete due to the way =
the
> cookie system works.
>=20
> So... to get this straight - "completion" means "I have finished processi=
ng this
> transaction".  It does not mean "I successfully processed this transactio=
n
> without any errors."
>=20

Thanks for your review.
So you mean that I should call vchan_cookie_complete no matter whether the =
error issue in QDMA?
I have some random DMA error test case, it seems work will.