From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ladislav Michl Subject: Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation Date: Fri, 10 Nov 2017 22:39:18 +0100 Message-ID: <20171110213918.pqq3ghblqhp2jwf2@lenoch> References: <20171109091155.6a6azfvjarwvlfh2@lenoch> <20171109091529.x3pqqvbiywj5aulo@lenoch> <3d33265a-2520-2298-6068-f76a7257bfd0@ti.com> <20171110100443.zqk7uzxoaq4eyntk@lenoch> <20171110152423.GM28152@atomide.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20171110152423.GM28152@atomide.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-mtd" Errors-To: linux-mtd-bounces+gldm-linux-mtd-36=gmane.org@lists.infradead.org To: Tony Lindgren Cc: Boris Brezillon , Peter Ujfalusi , Kyungmin Park , linux-mtd@lists.infradead.org, linux-omap@vger.kernel.org, Roger Quadros List-Id: linux-omap@vger.kernel.org On Fri, Nov 10, 2017 at 07:24:23AM -0800, Tony Lindgren wrote: > FYI, the gpio pin for onenand should not be in gpio mode. It should > be used as external dma request line to automatically trigger new > transfers like we do for tusb6010 dma. But of course it's possible > that onenand has other issues too preventing the dma usage. Now, after reading dma and interrupt related code again, I still do not see how the driver could be using hardware synchronized transfer. DMA seems to be used as a memcpy and gpio pin a ready/busy. Care to elaborate a bit more? Thank you, ladis ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/