[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191114091230.GB1249@jack.zhora.eu>
Date: Thu, 14 Nov 2019 11:12:30 +0200
From: Andi Shyti <andi@...zian.org>
To: Peter Ujfalusi <peter.ujfalusi@...com>
Cc: Andi Shyti <andi@...zian.org>, linus.walleij@...aro.org,
kgene@...nel.org, alexandre.belloni@...tlin.com,
linux-arm-msm@...r.kernel.org, radu_nicolae.pirea@....ro,
linux-spi@...r.kernel.org, linux-kernel@...r.kernel.org,
krzk@...nel.org, bjorn.andersson@...aro.org, vkoul@...nel.org,
agross@...nel.org, ldewangan@...dia.com, broonie@...nel.org,
linux-tegra@...r.kernel.org, thierry.reding@...il.com,
jonathanh@...dia.com, shawnguo@...nel.org, s.hauer@...gutronix.de,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 7/9] spi: s3c64xx: Use dma_request_chan() directly for
channel request
Hi Peter,
> >> if (!is_polling(sdd)) {
> >> /* Acquire DMA channels */
> >> - sdd->rx_dma.ch = dma_request_slave_channel_reason(&pdev->dev,
> >> - "rx");
> >> + sdd->rx_dma.ch = dma_request_chan(&pdev->dev, "rx");
> >
> > I have a little concern here. We have two funcions
> > 'dma_request_chan' and 'dma_request_channel' don't we end up
> > making some confusion here?
> >
> > Wouldn't it make more sense renaming 'dma_request_chan' to
> > 'dma_request_slave_channel_reason'?
>
> The dma_request_channel() should go away. It was the old API before we
> got the dma_slave_map for non DT (and non ACPI) platforms so we can get
> rid of the filter function exports from DMA drivers to clients all over
> the place.
Yes, I agree... thanks!
Acked-by: Andi Shyti <andi@...zian.org>
Thanks,
Andi
Powered by blists - more mailing lists