[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20060919113200.2afa1549@pb15>
Date: Tue, 19 Sep 2006 11:32:00 -0500
From: Olof Johansson <olof@...om.net>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
Cc: Dan Williams <dan.j.williams@...il.com>,
christopher.leech@...el.com, Jeff Garzik <jeff@...zik.org>,
neilb@...e.de, linux-raid@...r.kernel.org, akpm@...l.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] dmaengine: clean up and abstract function types (was
Re: [PATCH 08/19] dmaengine: enable multiple clients and operations)
On Tue, 19 Sep 2006 12:20:09 +0100 Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
> Ar Llu, 2006-09-18 am 20:05 -0500, ysgrifennodd Olof Johansson:
> > On Mon, 18 Sep 2006 15:56:37 -0700 "Dan Williams" <dan.j.williams@...il.com> wrote:
>
> > op.src_type = PG; op.src = pg;
> > op.dest_type = BUF; op.dest = buf;
> > op.len = len;
> > dma_async_commit(chan, op);
>
> At OLS Linus suggested it should distinguish between sync and async
> events for locking reasons.
>
> if(dma_async_commit(foo) == SYNC_COMPLETE) {
> finalise_stuff();
> }
>
> else /* will call foo->callback(foo->dev_id) */
>
> because otherwise you have locking complexities - the callback wants to
> take locks to guard the object it works on but if it is called
> synchronously - eg if hardware is busy and we fall back - it might
> deadlock with the caller of dmaa_async_foo() who also needs to hold the
> lock.
Good point, sounds very reasonable to me.
-Olof
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists