From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B83C9C3524A for ; Tue, 4 Feb 2020 08:13:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 93B282087E for ; Tue, 4 Feb 2020 08:13:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726406AbgBDINk (ORCPT ); Tue, 4 Feb 2020 03:13:40 -0500 Received: from mail-ot1-f68.google.com ([209.85.210.68]:38961 "EHLO mail-ot1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726189AbgBDINk (ORCPT ); Tue, 4 Feb 2020 03:13:40 -0500 Received: by mail-ot1-f68.google.com with SMTP id 77so16297201oty.6; Tue, 04 Feb 2020 00:13:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kOzfGH3X0V7ecKmEp3BZzWw2D7F64fbWXNLsPHZv3Qk=; b=I06b4qcYw2a+YqKHfHovDGMw9nYIicHHhZBgjaSpaAZUiUZwdqvUM58O9u8NL8qg7T HllGG6chJ04qBQ4nkKwxFIndOVlBpHtqMc6Y6ao4xDCcpcoyHYiX3kV6mt6ZgQWYmplB Q5LvqC92WgM+60BE8GqxSFG7/xl17joJJ5YaoCipYcAEwwk3LvgVL/ceoe2gCuyfkCgy u5r4moENdkaDIY1YZ+gzl3Tia+1tY7yMAUzL2gfMn4kcCp5yQfVXflGG782HUPkayzmh NPCHs7wkehjaRc2pa42qB7wKKxgjZZOi3Bt13hz1wfwYw9eYgzyGHOSBcnefw7ClmV6f BnAg== X-Gm-Message-State: APjAAAWDkcH/khYA1HjPF/PZPGHxypp9nmHo9ZbJsAufkuaeTAteRdw3 12YmDLGpHqPl7BTIoPE6bJr9ZwUxYGRaxWloPSTabCHs X-Google-Smtp-Source: APXvYqzBBbfQ012lpgP2RMvqRgR8Gp2+vA99nmHPTZXVWc6+0iUKHnH6KWrk+z3SoV9h6r6W7AXNIMmHDCOpoG3WrKM= X-Received: by 2002:a05:6830:1d55:: with SMTP id p21mr21313411oth.145.1580804018956; Tue, 04 Feb 2020 00:13:38 -0800 (PST) MIME-Version: 1.0 References: <20200203101806.2441-1-peter.ujfalusi@ti.com> <701ab186-c240-3c37-2c0b-8ac195f8073f@ti.com> <38f686ae-66fa-0e3a-ec2e-a09fc4054ac4@physik.fu-berlin.de> <00734e40-da0b-9d7f-20bc-ce1f9658dcd3@physik.fu-berlin.de> In-Reply-To: <00734e40-da0b-9d7f-20bc-ce1f9658dcd3@physik.fu-berlin.de> From: Geert Uytterhoeven Date: Tue, 4 Feb 2020 09:13:27 +0100 Message-ID: Subject: Re: [PATCH 0/3] dmaengine: Stear users towards dma_request_slave_chan() To: John Paul Adrian Glaubitz Cc: Peter Ujfalusi , Andy Shevchenko , Vinod Koul , dmaengine , Linux Kernel Mailing List , Dan Williams , Linux-sh list , Linux-Renesas Content-Type: text/plain; charset="UTF-8" Sender: dmaengine-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: dmaengine@vger.kernel.org Hi Adrian, On Mon, Feb 3, 2020 at 10:26 PM John Paul Adrian Glaubitz wrote: > On 2/3/20 9:34 PM, Geert Uytterhoeven wrote: > > On Mon, Feb 3, 2020 at 9:21 PM John Paul Adrian Glaubitz > > 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. > > Would it be possible to keep DMA support if device tree support was > added for SuperH? I think Rich eventually wanted to merge the patches, > there were just some minor issues with them. Adding DT support would definitely make things easier, but would be a lot of work. However, using dma_slave_map would be an alternative. > >>> 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. > > > > Does any of your SuperH boards use DMA? > > Anything interesting in /proc or /sys w.r.t. DMA? > > I have: > > root@tirpitz:/sys> find . -iname "*dma*" > ./bus/dma > ./bus/dma/devices/dma0 > ./bus/dma/devices/dma1 > ./bus/dma/devices/dma2 > ./bus/dma/devices/dma3 > ./bus/dma/devices/dma4 > ./bus/dma/devices/dma5 > ./bus/dma/devices/dma6 > ./bus/dma/devices/dma7 > ./bus/dma/devices/dma8 > ./bus/dma/devices/dma9 > ./bus/dma/devices/dma10 > ./bus/dma/devices/dma11 > ./bus/platform/devices/sh_dmac > ./bus/platform/devices/sh-dma-engine.0 > ./bus/platform/devices/sh-dma-engine.1 So you do have the two dmaengines... > On my SH-7785LCR. ... but are they actually used? git grep -E "(SHDMA|sh_dmae_slave_config)" -- "arch/sh/*7785*" doesn't come up with any matches, so I don't think any sh7785 platform is wired to use DMA (yet), only sh7757 and sh772[234]. To double-check: With current upstream, you can look for "slave" symlinks in sysfs. With older kernels, you can look at the interrupt counts for the DMACs in /proc/interrupts. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds