From: Peter Ujfalusi <peter.ujfalusi@ti.com>
To: Brian Norris <computersforpeace@gmail.com>
Cc: <kyungmin.park@samsung.com>, <dwmw2@infradead.org>,
<linux-mtd@lists.infradead.org>, <linux-kernel@vger.kernel.org>,
<linux-omap@vger.kernel.org>, Tony Lindgren <tony@atomide.com>
Subject: Re: [PATCH] mtd: onenand: omap2: Simplify the DMA setup for various paths
Date: Fri, 18 Dec 2015 21:48:09 +0200 [thread overview]
Message-ID: <567462F9.1010703@ti.com> (raw)
In-Reply-To: <20151218181111.GK10460@google.com>
On 12/18/2015 08:11 PM, Brian Norris wrote:
> On Mon, Dec 14, 2015 at 11:49:32AM +0200, Peter Ujfalusi wrote:
>> We have 4 functions containing almost identical DMA setup code. Create one
>> function which can set up the DMA for both read and write and use this in
>> place for the setup code in the driver.
>> The new function will use wait_for_completion_timeout() and it will figure
>> out the best data_type to be used for the transfer instead of hardwiring
>> 32 or 16 bit data.
>>
>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
>
> Does anyone use this driver? I've seen practically zero activity on the
> entire OneNAND codebase in the last few years, and I presumed it was
> essentially dead.
>
> If it's not dead, I'd like to know some contingency of people who are
> willing to actually maintain (or at least review) this stuff.
>
> Kyungmin, are you still out there? Or Tony, do you know of any users for
> this?
>
> Peter, are you actually using this, or are you just refactoring for the
> fun of it?
Not really for fun, but I want to get rid of all legacy/direct sDMA use so at
the end we will have omap_start_dma() visible in two files:
arch/arm/plat-omap/dma.c
drivers/dma/omap-dma.c
from there it will be possible to get rid of the plat-omap code. This onenand
driver was the first in the 'git grep omap_start_dma' result ;)
--
Péter
WARNING: multiple messages have this Message-ID (diff)
From: Peter Ujfalusi <peter.ujfalusi@ti.com>
To: Brian Norris <computersforpeace@gmail.com>
Cc: kyungmin.park@samsung.com, dwmw2@infradead.org,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-omap@vger.kernel.org, Tony Lindgren <tony@atomide.com>
Subject: Re: [PATCH] mtd: onenand: omap2: Simplify the DMA setup for various paths
Date: Fri, 18 Dec 2015 21:48:09 +0200 [thread overview]
Message-ID: <567462F9.1010703@ti.com> (raw)
In-Reply-To: <20151218181111.GK10460@google.com>
On 12/18/2015 08:11 PM, Brian Norris wrote:
> On Mon, Dec 14, 2015 at 11:49:32AM +0200, Peter Ujfalusi wrote:
>> We have 4 functions containing almost identical DMA setup code. Create one
>> function which can set up the DMA for both read and write and use this in
>> place for the setup code in the driver.
>> The new function will use wait_for_completion_timeout() and it will figure
>> out the best data_type to be used for the transfer instead of hardwiring
>> 32 or 16 bit data.
>>
>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
>
> Does anyone use this driver? I've seen practically zero activity on the
> entire OneNAND codebase in the last few years, and I presumed it was
> essentially dead.
>
> If it's not dead, I'd like to know some contingency of people who are
> willing to actually maintain (or at least review) this stuff.
>
> Kyungmin, are you still out there? Or Tony, do you know of any users for
> this?
>
> Peter, are you actually using this, or are you just refactoring for the
> fun of it?
Not really for fun, but I want to get rid of all legacy/direct sDMA use so at
the end we will have omap_start_dma() visible in two files:
arch/arm/plat-omap/dma.c
drivers/dma/omap-dma.c
from there it will be possible to get rid of the plat-omap code. This onenand
driver was the first in the 'git grep omap_start_dma' result ;)
--
Péter
next prev parent reply other threads:[~2015-12-18 19:49 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-14 9:49 [PATCH] mtd: onenand: omap2: Simplify the DMA setup for various paths Peter Ujfalusi
2015-12-14 9:49 ` Peter Ujfalusi
2015-12-18 18:11 ` Brian Norris
2015-12-18 18:39 ` Tony Lindgren
2015-12-19 13:30 ` Aaro Koskinen
2015-12-21 8:09 ` Peter Ujfalusi
2015-12-21 8:09 ` Peter Ujfalusi
2015-12-18 19:48 ` Peter Ujfalusi [this message]
2015-12-18 19:48 ` Peter Ujfalusi
2015-12-18 22:39 ` Brian Norris
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=567462F9.1010703@ti.com \
--to=peter.ujfalusi@ti.com \
--cc=computersforpeace@gmail.com \
--cc=dwmw2@infradead.org \
--cc=kyungmin.park@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=tony@atomide.com \
/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.