From: Rob Landley <rob@landley.net>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>,
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 04:18:06 -0600 [thread overview]
Message-ID: <3601f6ef-1666-2fd5-263c-388c0c48db16@landley.net> (raw)
In-Reply-To: <CAMuHMdVeCaRu=D9stdEuWKpnVm1YBibwuVrxogVx+2RBvOb1tA@mail.gmail.com>
On 2/4/20 3:27 AM, Geert Uytterhoeven wrote:
> Hi Rob,
>
> On Tue, Feb 4, 2020 at 10:12 AM Rob Landley <rob@landley.net> wrote:
>> On 2/4/20 2:01 AM, Geert Uytterhoeven wrote:
>>> 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 :(.
The problem with converting everything else to j-core has always been regression
testing. I have 2 pieces of classing sh4 hardware, and one classing sh2 board,
and none of them are currently on the same continent I am. :)
(I've got 3 different j-core boards, though. And am currently in the same room
as 2 others. :)
>>>>> 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.)
>
> And would use DT. Hence the issue is not applicable to j-core.
Indeed.
The last classic sh4 board I used did not have DMA hooked up in Linux, and
trying to make current kernels work hit the fact that the device tree people
kept breaking various pre-device tree APIs, and my patches to fix them were met
with "you should convert everything to device tree rather than fix this obvious
regression we caused" and thus never went upstream. (Johnson Controls shipped
them locally and I handed the patches over to the lawyers to do the license
compliance tarball before I left. And of course I posted the fixes to this list...)
It's nice that at least this time somebody is _asking_ before breaking
non-device-tree support for stuff that used to work...
>> 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...
>
> Is j32 the (rebranded) j4?
Yes.
Rob
next prev parent reply other threads:[~2020-02-04 10:13 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
2020-02-04 9:27 ` Geert Uytterhoeven
2020-02-04 10:18 ` Rob Landley [this message]
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=3601f6ef-1666-2fd5-263c-388c0c48db16@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).