Re: [PATCH 2/2] DMAENGINE: COH 901 318 fix bytesleft

From: Dan Williams
Date: Wed Mar 24 2010 - 17:35:11 EST


On Thu, Mar 4, 2010 at 6:40 AM, Linus Walleij
<linus.walleij@xxxxxxxxxxxxxx> wrote:
> This makes the function to get the number of bytes left in the
> ongoing DMA transaction actually work: the old code did not take
> neither lli:s nor queued jobs into account. Also fix a missing
> spinlock while we're at it.
>
> Signed-off-by: Linus Walleij <linus.walleij@xxxxxxxxxxxxxx>
> ----
> Sorry last version of the 0002 patch had a debug print stuck in
> it still. This one is fixed, both patches apply on top of the
> previous ones by the way, I'm digging around in this DMA driver
> now so might as well try to fix a number of issues with it.
> ---
>  drivers/dma/coh901318.c |   96 +++++++++++++++++++++++++++++++++++++++++++----
>  1 files changed, 88 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/dma/coh901318.c b/drivers/dma/coh901318.c
> index 20889c9..f636c4a 100644
> --- a/drivers/dma/coh901318.c
> +++ b/drivers/dma/coh901318.c
[..]
> @@ -831,6 +906,7 @@ static irqreturn_t dma_irq_handler(int irq, void *dev_id)
>  static int coh901318_alloc_chan_resources(struct dma_chan *chan)
>  {
>        struct coh901318_chan   *cohc = to_coh901318_chan(chan);
> +       unsigned long flags;
>
>        dev_vdbg(COHC_2_DEV(cohc), "[%s] DMA channel %d\n",
>                 __func__, cohc->id);
> @@ -838,11 +914,15 @@ static int coh901318_alloc_chan_resources(struct dma_chan *chan)
>        if (chan->client_count > 1)
>                return -EBUSY;
>
> +       spin_lock_irqsave(&cohc->lock, flags);
> +
>        coh901318_config(cohc, NULL);
>
>        cohc->allocated = 1;
>        cohc->completed = chan->cookie = 1;
>
> +       spin_unlock_irqrestore(&cohc->lock, flags);
> +
>

Should this hunk be broken off and sent to -stable? My guess is no.
It should be mostly impossible to trigger a problem here since the
channel is expected to be idle while resources are being allocated and
the dmaengine mutex is already protecting against parallel
allocations. It is an unrelated fix however.

--
Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/