Messages in this thread |  | | From | Geert Uytterhoeven <> | Date | Mon, 3 Feb 2020 14:32:35 +0100 | Subject | Re: [PATCH 0/3] dmaengine: Stear users towards dma_request_slave_chan() |
| |
Hi Peter,
On Mon, Feb 3, 2020 at 1:49 PM Peter Ujfalusi <peter.ujfalusi@ti.com> wrote: > On 03/02/2020 13.16, Andy Shevchenko wrote: > > On Mon, Feb 3, 2020 at 12:59 PM Peter Ujfalusi <peter.ujfalusi@ti.com> wrote: > >> On 03/02/2020 12.37, Andy Shevchenko wrote: > >>> On Mon, Feb 3, 2020 at 12:32 PM Peter Ujfalusi <peter.ujfalusi@ti.com> wrote: > >>>> Advise users of dma_request_slave_channel() and > >>>> dma_request_slave_channel_compat() to move to dma_request_slave_chan() > >>> > >>> How? There are legacy ARM boards you have to care / remove before. > >>> DMAengine subsystem makes a p*s off decisions > >> > >> The dma_slave_map support is added few years back for the legacy ARM > >> boards, because we do care. > >> daVinci, OMAP1, pxa, s3cx4xx and even m68k/coldfire moved over. > > > > Then why simple not to convert (start converting) those few drivers to > > new API and simple remove the old one? > > _if_ the dma_request_slave_channel_compat() is really falling back after > dma_request_chan() - this is what it calls first, then it is not a > simple convert to a new API. > 1. The arch needs to define the dma_slave_map for the SoC. > 2. The dma driver needs few lines to add it to DMAengine core (+pdata > change). > After this the _compat() can be replaced with dma_request_chan() > > In most cases I do not have access to documentation and boards to test. > > Looking at the output of 'git grep dma_request_slave_channel_compat': > drivers/mmc/host/renesas_sdhi_sys_dmac.c > drivers/spi/spi-pxa2xx-dma.c > drivers/spi/spi-rspi.c > drivers/spi/spi-sh-msiof.c > drivers/tty/serial/8250/8250_dma.c > > From these rspi boots only in DT and I'm not sure about the others.
Both rspi and sh-msiof have users on legacy SH (i.e. without DT):
arch/sh/kernel/cpu/sh4a/setup-sh7757.c: .name = "rspi", arch/sh/boards/mach-ecovec24/setup.c: .name = "spi_sh_msiof",
The former seems to be used with drivers/dma/sh/shdmac.c:
arch/sh/include/cpu-sh4/cpu/sh7757.h: SHDMA_SLAVE_RSPI_TX, arch/sh/include/cpu-sh4/cpu/sh7757.h: SHDMA_SLAVE_RSPI_RX, arch/sh/kernel/cpu/sh4a/setup-sh7757.c: .slave_id = SHDMA_SLAVE_RSPI_TX, arch/sh/kernel/cpu/sh4a/setup-sh7757.c: .slave_id = SHDMA_SLAVE_RSPI_RX,
but I have no idea if it still works (and no hardware).
The latter doesn't seem to be used with DMA on ecovec24/sh7724, so probably we can just drop the _compat() from sh-sh-msiof.c.
BTW, we no longer support non-legacy DMA in drivers/tty/serial/sh-sci.c (DMA was completely broken in that driver when I added DT suppport), but it seems it was used at some point on various SH, cfr. e.g. arch/sh/kernel/cpu/sh4a/setup-sh7724.c still setting up the channels. Which might be a motivation for just dropping _compat() from spi-rspi.c, too? ;-)
Anyone who cares for DMA on SuperH?
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
|  |