[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTik2_qFoT-CUhhWL6o5PN9m8RyE-R+0t1HUo9+oq@mail.gmail.com>
Date: Tue, 4 Jan 2011 09:41:02 +0900
From: Jassi Brar <jassisinghbrar@...il.com>
To: Russell King - ARM Linux <linux@....linux.org.uk>
Cc: Dan Williams <dan.j.williams@...el.com>,
Linus Walleij <linus.walleij@...ricsson.com>,
Viresh Kumar <viresh.kumar@...com>,
Kukjin Kim <kgene.kim@...sung.com>, yuanyabin1978@...a.com,
linux-kernel@...r.kernel.org, Ben Dooks <ben-linux@...ff.org>,
Peter Pearse <peter.pearse@....com>,
linux-arm-kernel@...ts.infradead.org,
Alessandro Rubini <rubini@...pv.it>
Subject: Re: [PATCH 06/13] DMAENGINE: driver for the ARM PL080/PL081 PrimeCells
On Tue, Jan 4, 2011 at 12:19 AM, Russell King - ARM Linux
<linux@....linux.org.uk> wrote:
> I've not decided whether it should be possible to resume an ETIMEOUT'd
> pause request (in theory with pl08x, that's just a matter of clearing
> the HALT bit) or whether an ETIMEOUT'd pause request should restore
> the previous HALT bit setting (possibly re-enabling transfers on the
> channel.) Allowing it to be re-enabled in some way would be the safest
> thing in terms of data integrity for the reason mentioned in the
> "important note" above.
Not sure if every DMAC could resume cleanly from exact pause point.
Perhaps the upper layer of client driver should take care of that, just
like ALSA which emulates pause/resume if the 'optional' capability is
not advertised by the audio dma driver.
--
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