From: Vinod Koul <vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
To: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Cc: Peter Griffin
<peter.griffin-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
kernel-F5mvAk5X5gdBDgjK7y7TUQ@public.gmane.org,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
leoli-KZfg59tc24xl57MIdRCFDg@public.gmane.org,
zw-aYo+Mbtxn2uXDw4h08c5KA@public.gmane.org,
baohua-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org,
wens-jdAy2FN1RRM@public.gmane.org,
ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org,
swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
Subject: Re: [PATCH 7/8] dmaengine: tegra20-apb-dma: Only calculate residue if txstate exists.
Date: Tue, 28 Jun 2016 09:34:02 +0530 [thread overview]
Message-ID: <20160628040402.GP22564@localhost> (raw)
In-Reply-To: <57697736.4050008-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On Tue, Jun 21, 2016 at 06:19:50PM +0100, Jon Hunter wrote:
>
> On 21/06/16 17:01, Vinod Koul wrote:
> > On Wed, Jun 08, 2016 at 09:51:57AM +0100, Jon Hunter wrote:
> >> Hi Peter,
> >>
> >> On 07/06/16 18:38, Peter Griffin wrote:
> >>> There is no point calculating the residue if there is
> >>> no txstate to store the value.
> >>>
> >>> Signed-off-by: Peter Griffin <peter.griffin-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> >>> ---
> >>> drivers/dma/tegra20-apb-dma.c | 2 +-
> >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma/tegra20-apb-dma.c
> >>> index 01e316f..7f4af8c 100644
> >>> --- a/drivers/dma/tegra20-apb-dma.c
> >>> +++ b/drivers/dma/tegra20-apb-dma.c
> >>> @@ -814,7 +814,7 @@ static enum dma_status tegra_dma_tx_status(struct dma_chan *dc,
> >>> unsigned int residual;
> >>>
> >>> ret = dma_cookie_status(dc, cookie, txstate);
> >>> - if (ret == DMA_COMPLETE)
> >>> + if (ret == DMA_COMPLETE || !txstate)
> >>> return ret;
> >>
> >> Thanks for reporting this. I agree that we should not do this, however,
> >> looking at the code for Tegra, I am wondering if this could change the
> >> actual state that is returned. Looking at dma_cookie_status() it will
> >> call dma_async_is_complete() which will return either DMA_COMPLETE or
> >> DMA_IN_PROGRESS. It could be possible that the actual state for the
> >> DMA transfer in the tegra driver is DMA_ERROR, so I am wondering if we
> >> should do something like the following ...
> >
> > This one is stopping code execution when residue is not valid. Do notice
> > that it check for DMA_COMPLETE OR txstate. In other cases, wit will return
> > 'that' state when txstate is NULL.
>
> Sorry what do you mean by "this one"?
the patch
>
> My point is that if the status is not DMA_COMPLETE, then it is possible
> that it could be DMA_ERROR (for tegra that is).
right it can be any state... and we check for only DMA_COMPLETE as residue
has no meaning.
> However,
> dma_cookie_status will only return DMA_IN_PROGRESS or DMA_COMPLETE and
> so if 'txstate' is NULL we will not see the DMA_ERROR status anymore and
> just think it is in progress when it is actually an error.
Yes that is an existing issue, if you are reporting DMA_ERROR then you
should add a check for DMA_ERROR as well and not do residue calculation for
that case.
>
> I do agree that the driver is broken as we are not checking for
> !txstate, but this also changes the behaviour a bit.
It changes for better and not worse. Btw pls feel free to send a patch
handling DMA_ERROR :)
--
~Vinod
WARNING: multiple messages have this Message-ID (diff)
From: Vinod Koul <vinod.koul@intel.com>
To: Jon Hunter <jonathanh@nvidia.com>
Cc: Peter Griffin <peter.griffin@linaro.org>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, kernel@stlinux.com,
linus.walleij@linaro.org, dan.j.williams@intel.com,
leoli@freescale.com, zw@zh-kernel.org, baohua@kernel.org,
maxime.ripard@free-electrons.com, wens@csie.org,
ldewangan@nvidia.com, swarren@wwwdotorg.org,
thierry.reding@gmail.com, gnurou@gmail.com, lee.jones@linaro.org,
dmaengine@vger.kernel.org, linux-tegra@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 7/8] dmaengine: tegra20-apb-dma: Only calculate residue if txstate exists.
Date: Tue, 28 Jun 2016 09:34:02 +0530 [thread overview]
Message-ID: <20160628040402.GP22564@localhost> (raw)
In-Reply-To: <57697736.4050008@nvidia.com>
On Tue, Jun 21, 2016 at 06:19:50PM +0100, Jon Hunter wrote:
>
> On 21/06/16 17:01, Vinod Koul wrote:
> > On Wed, Jun 08, 2016 at 09:51:57AM +0100, Jon Hunter wrote:
> >> Hi Peter,
> >>
> >> On 07/06/16 18:38, Peter Griffin wrote:
> >>> There is no point calculating the residue if there is
> >>> no txstate to store the value.
> >>>
> >>> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> >>> ---
> >>> drivers/dma/tegra20-apb-dma.c | 2 +-
> >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma/tegra20-apb-dma.c
> >>> index 01e316f..7f4af8c 100644
> >>> --- a/drivers/dma/tegra20-apb-dma.c
> >>> +++ b/drivers/dma/tegra20-apb-dma.c
> >>> @@ -814,7 +814,7 @@ static enum dma_status tegra_dma_tx_status(struct dma_chan *dc,
> >>> unsigned int residual;
> >>>
> >>> ret = dma_cookie_status(dc, cookie, txstate);
> >>> - if (ret == DMA_COMPLETE)
> >>> + if (ret == DMA_COMPLETE || !txstate)
> >>> return ret;
> >>
> >> Thanks for reporting this. I agree that we should not do this, however,
> >> looking at the code for Tegra, I am wondering if this could change the
> >> actual state that is returned. Looking at dma_cookie_status() it will
> >> call dma_async_is_complete() which will return either DMA_COMPLETE or
> >> DMA_IN_PROGRESS. It could be possible that the actual state for the
> >> DMA transfer in the tegra driver is DMA_ERROR, so I am wondering if we
> >> should do something like the following ...
> >
> > This one is stopping code execution when residue is not valid. Do notice
> > that it check for DMA_COMPLETE OR txstate. In other cases, wit will return
> > 'that' state when txstate is NULL.
>
> Sorry what do you mean by "this one"?
the patch
>
> My point is that if the status is not DMA_COMPLETE, then it is possible
> that it could be DMA_ERROR (for tegra that is).
right it can be any state... and we check for only DMA_COMPLETE as residue
has no meaning.
> However,
> dma_cookie_status will only return DMA_IN_PROGRESS or DMA_COMPLETE and
> so if 'txstate' is NULL we will not see the DMA_ERROR status anymore and
> just think it is in progress when it is actually an error.
Yes that is an existing issue, if you are reporting DMA_ERROR then you
should add a check for DMA_ERROR as well and not do residue calculation for
that case.
>
> I do agree that the driver is broken as we are not checking for
> !txstate, but this also changes the behaviour a bit.
It changes for better and not worse. Btw pls feel free to send a patch
handling DMA_ERROR :)
--
~Vinod
WARNING: multiple messages have this Message-ID (diff)
From: vinod.koul@intel.com (Vinod Koul)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 7/8] dmaengine: tegra20-apb-dma: Only calculate residue if txstate exists.
Date: Tue, 28 Jun 2016 09:34:02 +0530 [thread overview]
Message-ID: <20160628040402.GP22564@localhost> (raw)
In-Reply-To: <57697736.4050008@nvidia.com>
On Tue, Jun 21, 2016 at 06:19:50PM +0100, Jon Hunter wrote:
>
> On 21/06/16 17:01, Vinod Koul wrote:
> > On Wed, Jun 08, 2016 at 09:51:57AM +0100, Jon Hunter wrote:
> >> Hi Peter,
> >>
> >> On 07/06/16 18:38, Peter Griffin wrote:
> >>> There is no point calculating the residue if there is
> >>> no txstate to store the value.
> >>>
> >>> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> >>> ---
> >>> drivers/dma/tegra20-apb-dma.c | 2 +-
> >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma/tegra20-apb-dma.c
> >>> index 01e316f..7f4af8c 100644
> >>> --- a/drivers/dma/tegra20-apb-dma.c
> >>> +++ b/drivers/dma/tegra20-apb-dma.c
> >>> @@ -814,7 +814,7 @@ static enum dma_status tegra_dma_tx_status(struct dma_chan *dc,
> >>> unsigned int residual;
> >>>
> >>> ret = dma_cookie_status(dc, cookie, txstate);
> >>> - if (ret == DMA_COMPLETE)
> >>> + if (ret == DMA_COMPLETE || !txstate)
> >>> return ret;
> >>
> >> Thanks for reporting this. I agree that we should not do this, however,
> >> looking at the code for Tegra, I am wondering if this could change the
> >> actual state that is returned. Looking at dma_cookie_status() it will
> >> call dma_async_is_complete() which will return either DMA_COMPLETE or
> >> DMA_IN_PROGRESS. It could be possible that the actual state for the
> >> DMA transfer in the tegra driver is DMA_ERROR, so I am wondering if we
> >> should do something like the following ...
> >
> > This one is stopping code execution when residue is not valid. Do notice
> > that it check for DMA_COMPLETE OR txstate. In other cases, wit will return
> > 'that' state when txstate is NULL.
>
> Sorry what do you mean by "this one"?
the patch
>
> My point is that if the status is not DMA_COMPLETE, then it is possible
> that it could be DMA_ERROR (for tegra that is).
right it can be any state... and we check for only DMA_COMPLETE as residue
has no meaning.
> However,
> dma_cookie_status will only return DMA_IN_PROGRESS or DMA_COMPLETE and
> so if 'txstate' is NULL we will not see the DMA_ERROR status anymore and
> just think it is in progress when it is actually an error.
Yes that is an existing issue, if you are reporting DMA_ERROR then you
should add a check for DMA_ERROR as well and not do residue calculation for
that case.
>
> I do agree that the driver is broken as we are not checking for
> !txstate, but this also changes the behaviour a bit.
It changes for better and not worse. Btw pls feel free to send a patch
handling DMA_ERROR :)
--
~Vinod
next prev parent reply other threads:[~2016-06-28 4:04 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-07 17:38 [PATCH 0/8] Various dmaengine cleanups Peter Griffin
2016-06-07 17:38 ` Peter Griffin
2016-06-07 17:38 ` Peter Griffin
2016-06-07 17:38 ` [PATCH 1/8] dmaengine: fsl-edma: Fix clock handling error paths Peter Griffin
2016-06-07 17:38 ` Peter Griffin
2016-06-07 17:38 ` Peter Griffin
2016-06-07 17:38 ` [PATCH 2/8] dmaengine: fsl-edma: print error code in error messages Peter Griffin
2016-06-07 17:38 ` Peter Griffin
2016-06-07 17:38 ` Peter Griffin
2016-06-07 17:38 ` [PATCH 3/8] dmaengine: coh901318: Only calculate residue if txstate exists Peter Griffin
2016-06-07 17:38 ` Peter Griffin
[not found] ` <1465321121-22238-4-git-send-email-peter.griffin-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-06-08 12:15 ` Linus Walleij
2016-06-08 12:15 ` Linus Walleij
2016-06-08 12:15 ` Linus Walleij
2016-06-07 17:38 ` [PATCH 4/8] dmaengine: s3c24xx: Simplify code in s3c24xx_dma_tx_status() Peter Griffin
2016-06-07 17:38 ` Peter Griffin
2016-06-07 17:38 ` Peter Griffin
2016-06-07 17:38 ` [PATCH 5/8] dmaengine: ste_dma40: Only calculate residue if txstate exists Peter Griffin
2016-06-07 17:38 ` Peter Griffin
[not found] ` <1465321121-22238-6-git-send-email-peter.griffin-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-06-08 12:15 ` Linus Walleij
2016-06-08 12:15 ` Linus Walleij
2016-06-08 12:15 ` Linus Walleij
2016-06-07 17:38 ` [PATCH 6/8] dmaengine: sun6i-dma: Only calculate residue if state exists Peter Griffin
2016-06-07 17:38 ` Peter Griffin
2016-06-07 17:38 ` [PATCH 7/8] dmaengine: tegra20-apb-dma: Only calculate residue if txstate exists Peter Griffin
2016-06-07 17:38 ` Peter Griffin
2016-06-07 17:38 ` Peter Griffin
[not found] ` <1465321121-22238-8-git-send-email-peter.griffin-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-06-08 8:51 ` Jon Hunter
2016-06-08 8:51 ` Jon Hunter
2016-06-08 8:51 ` Jon Hunter
[not found] ` <5757DCAD.1090106-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-06-21 16:01 ` Vinod Koul
2016-06-21 16:01 ` Vinod Koul
2016-06-21 16:01 ` Vinod Koul
2016-06-21 17:19 ` Jon Hunter
2016-06-21 17:19 ` Jon Hunter
2016-06-21 17:19 ` Jon Hunter
[not found] ` <57697736.4050008-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-06-28 4:04 ` Vinod Koul [this message]
2016-06-28 4:04 ` Vinod Koul
2016-06-28 4:04 ` Vinod Koul
2016-06-07 17:38 ` [PATCH 8/8] dmaengine: Remove site specific OOM error messages on kzalloc Peter Griffin
2016-06-07 17:38 ` Peter Griffin
2016-06-08 8:22 ` Jon Hunter
2016-06-08 8:22 ` Jon Hunter
2016-06-08 8:22 ` Jon Hunter
[not found] ` <1465321121-22238-9-git-send-email-peter.griffin-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-06-08 12:12 ` Linus Walleij
2016-06-08 12:12 ` Linus Walleij
2016-06-08 12:12 ` Linus Walleij
2016-06-09 15:30 ` Lee Jones
2016-06-09 15:30 ` Lee Jones
2016-06-15 17:08 ` Vinod Koul
2016-06-15 17:08 ` Vinod Koul
2016-06-21 16:05 ` [PATCH 0/8] Various dmaengine cleanups Vinod Koul
2016-06-21 16:05 ` Vinod Koul
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160628040402.GP22564@localhost \
--to=vinod.koul-ral2jqcrhueavxtiumwx3w@public.gmane.org \
--cc=baohua-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
--cc=kernel-F5mvAk5X5gdBDgjK7y7TUQ@public.gmane.org \
--cc=ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
--cc=lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=leoli-KZfg59tc24xl57MIdRCFDg@public.gmane.org \
--cc=linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
--cc=maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org \
--cc=peter.griffin-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org \
--cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=wens-jdAy2FN1RRM@public.gmane.org \
--cc=zw-aYo+Mbtxn2uXDw4h08c5KA@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.