From: Rob Landley <rob@landley.net>
To: Geert Uytterhoeven <geert@linux-m68k.org>,
Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
Andy Shevchenko <andy.shevchenko@gmail.com>,
Vinod Koul <vkoul@kernel.org>,
dmaengine <dmaengine@vger.kernel.org>,
Dan Williams <dan.j.williams@intel.com>,
Linux-sh list <linux-sh@vger.kernel.org>,
Linux-Renesas <linux-renesas-soc@vger.kernel.org>
Subject: Re: [PATCH 0/3] dmaengine: Stear users towards dma_request_slave_chan()
Date: Tue, 4 Feb 2020 03:16:58 -0600 [thread overview]
Message-ID: <64cffbfe-a639-c09d-8aa2-fdda8fad2cf7@landley.net> (raw)
In-Reply-To: <CAMuHMdUYcSPoK8NOSdMzU_Jtg84aPMNKeGnacnF7=aidV4eqvw@mail.gmail.com>
On 2/4/20 2:01 AM, Geert Uytterhoeven wrote:
> Hi Peter,
>
> On Tue, Feb 4, 2020 at 7:52 AM Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
>> On 03/02/2020 22.34, Geert Uytterhoeven wrote:
>>> On Mon, Feb 3, 2020 at 9:21 PM John Paul Adrian Glaubitz
>>> <glaubitz@physik.fu-berlin.de> wrote:
>>>> On 2/3/20 2:32 PM, Geert Uytterhoeven wrote:
>>>>> Both rspi and sh-msiof have users on legacy SH (i.e. without DT):
>>>>
>>>> FWIW, there is a patch set by Yoshinori Sato to add device tree support
>>>> for classical SuperH hardware. It was never merged, unfortunately :(.
>>>
>>> True.
>>>
>>>>> Anyone who cares for DMA on SuperH?
>>>>
>>>> What is DMA used for on SuperH? Wouldn't dropping it cut support for
>>>> essential hardware features?
>>>
>>> It may make a few things slower.
The j-core stuff has DMA but we haven't hooked it up to dmaengine yet. (It's on
the todo list but pretty far down.)
I fought with dmaengine in a 7760 board in 2018, and got it to run its tests but
the ship deadline arrived before I got the ethernet working with it.
I found the documentation fairly impenetrable, is there a good primer on what's
_current_ for new implementations? (I had similar questions for gpio. It's easy
to google for "here's how you did it in 2010"...)
>> I would not drop DMA support but I would suggest to add dma_slave_map
>> for non DT boot so the _compat() can be dropped.
>
> Which is similar in spirit to gpiod_lookup and clk_register_clkdev(),
> right?
>
>> Imho on lower spec SoC (and I believe SuperH is) the DMA makes big
>> difference offloading data movement from the CPU.
>
> Assumed it is actually used...
The turtle boards need it USB, ethernet, and sdcard, but Rich Felker hasn't
finished the j32 port yet (we just got him the updated docs last month) and the
existing implementation is nommu so the things that are using it are reaching
around behind the OS's back...
Rob
next prev parent reply other threads:[~2020-02-04 9:12 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-03 10:18 [PATCH 0/3] dmaengine: Stear users towards dma_request_slave_chan() Peter Ujfalusi
2020-02-03 10:18 ` [PATCH 1/3] dmaengine: Remove unused define for dma_request_slave_channel_reason() Peter Ujfalusi
2020-02-03 13:35 ` Geert Uytterhoeven
2020-02-03 10:18 ` [PATCH 2/3] dmaengine: Mark dma_request_slave_channel() deprecated Peter Ujfalusi
2020-02-03 10:18 ` [PATCH 3/3] dmaengine: Encourage dma_request_slave_channel_compat() users to migrate Peter Ujfalusi
2020-02-03 10:35 ` Andy Shevchenko
2020-02-03 10:37 ` [PATCH 0/3] dmaengine: Stear users towards dma_request_slave_chan() Andy Shevchenko
2020-02-03 10:59 ` Peter Ujfalusi
2020-02-03 11:16 ` Andy Shevchenko
2020-02-03 12:09 ` Peter Ujfalusi
2020-02-03 12:48 ` Andy Shevchenko
2020-02-03 13:32 ` Geert Uytterhoeven
2020-02-03 20:21 ` John Paul Adrian Glaubitz
2020-02-03 20:34 ` Geert Uytterhoeven
2020-02-03 21:26 ` John Paul Adrian Glaubitz
2020-02-04 8:13 ` Geert Uytterhoeven
2020-02-04 6:52 ` Peter Ujfalusi
2020-02-04 8:01 ` Geert Uytterhoeven
2020-02-04 8:15 ` Peter Ujfalusi
2020-02-04 8:21 ` Peter Ujfalusi
2020-02-04 9:16 ` Rob Landley [this message]
2020-02-04 9:27 ` Geert Uytterhoeven
2020-02-04 10:18 ` Rob Landley
2020-02-04 6:21 ` Vinod Koul
2020-02-04 11:21 ` Andy Shevchenko
2020-02-05 4:43 ` Vinod Koul
2020-02-05 8:10 ` Peter Ujfalusi
2020-02-05 11:31 ` Vinod Koul
2020-02-05 11:56 ` Peter Ujfalusi
2020-02-05 11:59 ` Vinod Koul
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=64cffbfe-a639-c09d-8aa2-fdda8fad2cf7@landley.net \
--to=rob@landley.net \
--cc=andy.shevchenko@gmail.com \
--cc=dan.j.williams@intel.com \
--cc=dmaengine@vger.kernel.org \
--cc=geert@linux-m68k.org \
--cc=glaubitz@physik.fu-berlin.de \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=peter.ujfalusi@ti.com \
--cc=vkoul@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).