* [PATCH 01/18] MIPS: lantiq: pass struct device to DMA API functions
2019-02-01 8:47 don't pass a NULL struct device to DMA API functions Christoph Hellwig
@ 2019-02-01 8:47 ` Christoph Hellwig
2019-02-07 23:29 ` Paul Burton
2019-02-12 17:41 ` Paul Burton
2019-02-01 8:47 ` [PATCH 02/18] dmaengine: imx-sdma: " Christoph Hellwig
` (17 subsequent siblings)
18 siblings, 2 replies; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01 8:47 UTC (permalink / raw)
To: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel
Cc: iommu
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Also use GFP_KERNEL instead of GFP_ATOMIC as the gfp_t for the memory
allocation, as we aren't in interrupt context or under a lock.
Note that this whole function looks somewhat bogus given that we never
even look at the returned dma address, and the CPHYSADDR magic on
a returned noncached mapping looks "interesting". But I'll leave
that to people more familiar with the code to sort out.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/mips/lantiq/xway/vmmc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/mips/lantiq/xway/vmmc.c b/arch/mips/lantiq/xway/vmmc.c
index 577ec81b557d..3deab9a77718 100644
--- a/arch/mips/lantiq/xway/vmmc.c
+++ b/arch/mips/lantiq/xway/vmmc.c
@@ -31,8 +31,8 @@ static int vmmc_probe(struct platform_device *pdev)
dma_addr_t dma;
cp1_base =
- (void *) CPHYSADDR(dma_alloc_coherent(NULL, CP1_SIZE,
- &dma, GFP_ATOMIC));
+ (void *) CPHYSADDR(dma_alloc_coherent(&pdev->dev, CP1_SIZE,
+ &dma, GFP_KERNEL));
gpio_count = of_gpio_count(pdev->dev.of_node);
while (gpio_count > 0) {
--
2.20.1
^ permalink raw reply related [flat|nested] 41+ messages in thread
* Re: [PATCH 01/18] MIPS: lantiq: pass struct device to DMA API functions
2019-02-01 8:47 ` [PATCH 01/18] MIPS: lantiq: pass " Christoph Hellwig
@ 2019-02-07 23:29 ` Paul Burton
2019-02-12 7:45 ` Christoph Hellwig
2019-02-12 17:41 ` Paul Burton
1 sibling, 1 reply; 41+ messages in thread
From: Paul Burton @ 2019-02-07 23:29 UTC (permalink / raw)
To: Christoph Hellwig
Cc: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel, iommu
Hi Christoph,
On Fri, Feb 01, 2019 at 09:47:44AM +0100, Christoph Hellwig wrote:
> The DMA API generally relies on a struct device to work properly, and
> only barely works without one for legacy reasons. Pass the easily
> available struct device from the platform_device to remedy this.
>
> Also use GFP_KERNEL instead of GFP_ATOMIC as the gfp_t for the memory
> allocation, as we aren't in interrupt context or under a lock.
>
> Note that this whole function looks somewhat bogus given that we never
> even look at the returned dma address, and the CPHYSADDR magic on
> a returned noncached mapping looks "interesting". But I'll leave
> that to people more familiar with the code to sort out.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> arch/mips/lantiq/xway/vmmc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Would you like this to go through the MIPS tree or elsewhere? If the
latter:
Acked-by: Paul Burton <paul.burton@mips.com>
Thanks,
Paul
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH 01/18] MIPS: lantiq: pass struct device to DMA API functions
2019-02-07 23:29 ` Paul Burton
@ 2019-02-12 7:45 ` Christoph Hellwig
0 siblings, 0 replies; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-12 7:45 UTC (permalink / raw)
To: Paul Burton
Cc: Christoph Hellwig, John Crispin, Vinod Koul, Dmitry Tarnyagin,
Nicolas Ferre, Sudip Mukherjee, Felipe Balbi, linux-mips,
linux-kernel, dmaengine, netdev, linux-usb, linux-fbdev,
alsa-devel, iommu
On Thu, Feb 07, 2019 at 11:29:14PM +0000, Paul Burton wrote:
> Would you like this to go through the MIPS tree or elsewhere? If the
> latter:
>
> Acked-by: Paul Burton <paul.burton@mips.com>
Please pick it up through the mips tree!
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH 01/18] MIPS: lantiq: pass struct device to DMA API functions
2019-02-01 8:47 ` [PATCH 01/18] MIPS: lantiq: pass " Christoph Hellwig
2019-02-07 23:29 ` Paul Burton
@ 2019-02-12 17:41 ` Paul Burton
1 sibling, 0 replies; 41+ messages in thread
From: Paul Burton @ 2019-02-12 17:41 UTC (permalink / raw)
To: Christoph Hellwig
Cc: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel, iommu,
linux-mips
Hello,
Christoph Hellwig wrote:
> The DMA API generally relies on a struct device to work properly, and
> only barely works without one for legacy reasons. Pass the easily
> available struct device from the platform_device to remedy this.
>
> Also use GFP_KERNEL instead of GFP_ATOMIC as the gfp_t for the memory
> allocation, as we aren't in interrupt context or under a lock.
>
> Note that this whole function looks somewhat bogus given that we never
> even look at the returned dma address, and the CPHYSADDR magic on
> a returned noncached mapping looks "interesting". But I'll leave
> that to people more familiar with the code to sort out.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Applied to mips-fixes.
Thanks,
Paul
[ This message was auto-generated; if you believe anything is incorrect
then please email paul.burton@mips.com to report it. ]
^ permalink raw reply [flat|nested] 41+ messages in thread
* [PATCH 02/18] dmaengine: imx-sdma: pass struct device to DMA API functions
2019-02-01 8:47 don't pass a NULL struct device to DMA API functions Christoph Hellwig
2019-02-01 8:47 ` [PATCH 01/18] MIPS: lantiq: pass " Christoph Hellwig
@ 2019-02-01 8:47 ` Christoph Hellwig
2019-02-02 10:11 ` Vinod Koul
2019-02-01 8:47 ` [PATCH 03/18] net: caif: " Christoph Hellwig
` (16 subsequent siblings)
18 siblings, 1 reply; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01 8:47 UTC (permalink / raw)
To: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel
Cc: iommu
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/dma/imx-sdma.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 86708fb9bda1..0b6bba0b9f38 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -677,7 +677,7 @@ static int sdma_load_script(struct sdma_engine *sdma, void *buf, int size,
int ret;
unsigned long flags;
- buf_virt = dma_alloc_coherent(NULL, size, &buf_phys, GFP_KERNEL);
+ buf_virt = dma_alloc_coherent(sdma->dev, size, &buf_phys, GFP_KERNEL);
if (!buf_virt) {
return -ENOMEM;
}
@@ -696,7 +696,7 @@ static int sdma_load_script(struct sdma_engine *sdma, void *buf, int size,
spin_unlock_irqrestore(&sdma->channel_0_lock, flags);
- dma_free_coherent(NULL, size, buf_virt, buf_phys);
+ dma_free_coherent(sdma->dev, size, buf_virt, buf_phys);
return ret;
}
@@ -1182,8 +1182,8 @@ static int sdma_request_channel0(struct sdma_engine *sdma)
{
int ret = -EBUSY;
- sdma->bd0 = dma_alloc_coherent(NULL, PAGE_SIZE, &sdma->bd0_phys,
- GFP_NOWAIT);
+ sdma->bd0 = dma_alloc_coherent(sdma->dev, PAGE_SIZE, &sdma->bd0_phys,
+ GFP_NOWAIT);
if (!sdma->bd0) {
ret = -ENOMEM;
goto out;
@@ -1842,7 +1842,7 @@ static int sdma_init(struct sdma_engine *sdma)
/* Be sure SDMA has not started yet */
writel_relaxed(0, sdma->regs + SDMA_H_C0PTR);
- sdma->channel_control = dma_alloc_coherent(NULL,
+ sdma->channel_control = dma_alloc_coherent(sdma->dev,
MAX_DMA_CHANNELS * sizeof (struct sdma_channel_control) +
sizeof(struct sdma_context_data),
&ccb_phys, GFP_KERNEL);
--
2.20.1
^ permalink raw reply related [flat|nested] 41+ messages in thread
* Re: [PATCH 02/18] dmaengine: imx-sdma: pass struct device to DMA API functions
2019-02-01 8:47 ` [PATCH 02/18] dmaengine: imx-sdma: " Christoph Hellwig
@ 2019-02-02 10:11 ` Vinod Koul
2019-02-02 17:21 ` Christoph Hellwig
0 siblings, 1 reply; 41+ messages in thread
From: Vinod Koul @ 2019-02-02 10:11 UTC (permalink / raw)
To: Christoph Hellwig
Cc: John Crispin, Dmitry Tarnyagin, Nicolas Ferre, Sudip Mukherjee,
Felipe Balbi, linux-mips, linux-kernel, dmaengine, netdev,
linux-usb, linux-fbdev, alsa-devel, iommu
On 01-02-19, 09:47, Christoph Hellwig wrote:
> The DMA API generally relies on a struct device to work properly, and
> only barely works without one for legacy reasons. Pass the easily
> available struct device from the platform_device to remedy this.
This looks good to me but fails to apply. Can you please base it on
dmaengine-next or linux-next please and resend
Thanks
--
~Vinod
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH 02/18] dmaengine: imx-sdma: pass struct device to DMA API functions
2019-02-02 10:11 ` Vinod Koul
@ 2019-02-02 17:21 ` Christoph Hellwig
0 siblings, 0 replies; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-02 17:21 UTC (permalink / raw)
To: Vinod Koul
Cc: Christoph Hellwig, John Crispin, Dmitry Tarnyagin, Nicolas Ferre,
Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel, iommu
On Sat, Feb 02, 2019 at 03:41:21PM +0530, Vinod Koul wrote:
> On 01-02-19, 09:47, Christoph Hellwig wrote:
> > The DMA API generally relies on a struct device to work properly, and
> > only barely works without one for legacy reasons. Pass the easily
> > available struct device from the platform_device to remedy this.
>
> This looks good to me but fails to apply. Can you please base it on
> dmaengine-next or linux-next please and resend
commit ceaf52265148d3a5ca24237fd1c709caa5f46184
Author: Andy Duan <fugang.duan@nxp.com>
Date: Fri Jan 11 14:29:49 2019 +0000
dmaengine: imx-sdma: pass ->dev to dma_alloc_coherent() API
in linux-next actually is equivalent to this patch, so we can drop
this one.
>
> Thanks
> --
> ~Vinod
---end quoted text---
^ permalink raw reply [flat|nested] 41+ messages in thread
* [PATCH 03/18] net: caif: pass struct device to DMA API functions
2019-02-01 8:47 don't pass a NULL struct device to DMA API functions Christoph Hellwig
2019-02-01 8:47 ` [PATCH 01/18] MIPS: lantiq: pass " Christoph Hellwig
2019-02-01 8:47 ` [PATCH 02/18] dmaengine: imx-sdma: " Christoph Hellwig
@ 2019-02-01 8:47 ` Christoph Hellwig
2019-02-01 13:53 ` Robin Murphy
2019-02-01 8:47 ` [PATCH 04/18] au1000_eth: " Christoph Hellwig
` (15 subsequent siblings)
18 siblings, 1 reply; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01 8:47 UTC (permalink / raw)
To: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel
Cc: iommu
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Also use the proper Kconfig symbol to check for DMA API availability.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/net/caif/caif_spi.c | 30 ++++++++++++++++--------------
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/drivers/net/caif/caif_spi.c b/drivers/net/caif/caif_spi.c
index d28a1398c091..b7f3e263b57c 100644
--- a/drivers/net/caif/caif_spi.c
+++ b/drivers/net/caif/caif_spi.c
@@ -73,35 +73,37 @@ MODULE_PARM_DESC(spi_down_tail_align, "SPI downlink tail alignment.");
#define LOW_WATER_MARK 100
#define HIGH_WATER_MARK (LOW_WATER_MARK*5)
-#ifdef CONFIG_UML
+#ifdef CONFIG_HAS_DMA
/*
* We sometimes use UML for debugging, but it cannot handle
* dma_alloc_coherent so we have to wrap it.
*/
-static inline void *dma_alloc(dma_addr_t *daddr)
+static inline void *dma_alloc(struct cfspi *cfspi, dma_addr_t *daddr)
{
return kmalloc(SPI_DMA_BUF_LEN, GFP_KERNEL);
}
-static inline void dma_free(void *cpu_addr, dma_addr_t handle)
+static inline void dma_free(struct cfspi *cfspi, void *cpu_addr,
+ dma_addr_t handle)
{
kfree(cpu_addr);
}
#else
-static inline void *dma_alloc(dma_addr_t *daddr)
+static inline void *dma_alloc(struct cfspi *cfspi, dma_addr_t *daddr)
{
- return dma_alloc_coherent(NULL, SPI_DMA_BUF_LEN, daddr,
+ return dma_alloc_coherent(&cfspi->pdev->dev, SPI_DMA_BUF_LEN, daddr,
GFP_KERNEL);
}
-static inline void dma_free(void *cpu_addr, dma_addr_t handle)
+static inline void dma_free(struct cfspi *cfspi, void *cpu_addr,
+ dma_addr_t handle)
{
- dma_free_coherent(NULL, SPI_DMA_BUF_LEN, cpu_addr, handle);
+ dma_free_coherent(&cfspi->pdev->dev, SPI_DMA_BUF_LEN, cpu_addr, handle);
}
-#endif /* CONFIG_UML */
+#endif /* CONFIG_HAS_DMA */
#ifdef CONFIG_DEBUG_FS
@@ -610,13 +612,13 @@ static int cfspi_init(struct net_device *dev)
}
/* Allocate DMA buffers. */
- cfspi->xfer.va_tx[0] = dma_alloc(&cfspi->xfer.pa_tx[0]);
+ cfspi->xfer.va_tx[0] = dma_alloc(cfspi, &cfspi->xfer.pa_tx[0]);
if (!cfspi->xfer.va_tx[0]) {
res = -ENODEV;
goto err_dma_alloc_tx_0;
}
- cfspi->xfer.va_rx = dma_alloc(&cfspi->xfer.pa_rx);
+ cfspi->xfer.va_rx = dma_alloc(cfspi, &cfspi->xfer.pa_rx);
if (!cfspi->xfer.va_rx) {
res = -ENODEV;
@@ -665,9 +667,9 @@ static int cfspi_init(struct net_device *dev)
return 0;
err_create_wq:
- dma_free(cfspi->xfer.va_rx, cfspi->xfer.pa_rx);
+ dma_free(cfspi, cfspi->xfer.va_rx, cfspi->xfer.pa_rx);
err_dma_alloc_rx:
- dma_free(cfspi->xfer.va_tx[0], cfspi->xfer.pa_tx[0]);
+ dma_free(cfspi, cfspi->xfer.va_tx[0], cfspi->xfer.pa_tx[0]);
err_dma_alloc_tx_0:
return res;
}
@@ -683,8 +685,8 @@ static void cfspi_uninit(struct net_device *dev)
cfspi->ndev = NULL;
/* Free DMA buffers. */
- dma_free(cfspi->xfer.va_rx, cfspi->xfer.pa_rx);
- dma_free(cfspi->xfer.va_tx[0], cfspi->xfer.pa_tx[0]);
+ dma_free(cfspi, cfspi->xfer.va_rx, cfspi->xfer.pa_rx);
+ dma_free(cfspi, cfspi->xfer.va_tx[0], cfspi->xfer.pa_tx[0]);
set_bit(SPI_TERMINATE, &cfspi->state);
wake_up_interruptible(&cfspi->wait);
destroy_workqueue(cfspi->wq);
--
2.20.1
^ permalink raw reply related [flat|nested] 41+ messages in thread
* Re: [PATCH 03/18] net: caif: pass struct device to DMA API functions
2019-02-01 8:47 ` [PATCH 03/18] net: caif: " Christoph Hellwig
@ 2019-02-01 13:53 ` Robin Murphy
2019-02-01 16:10 ` Christoph Hellwig
0 siblings, 1 reply; 41+ messages in thread
From: Robin Murphy @ 2019-02-01 13:53 UTC (permalink / raw)
To: Christoph Hellwig, John Crispin, Vinod Koul, Dmitry Tarnyagin,
Nicolas Ferre, Sudip Mukherjee, Felipe Balbi, linux-mips,
linux-kernel, dmaengine, netdev, linux-usb, linux-fbdev,
alsa-devel
Cc: iommu
On 01/02/2019 08:47, Christoph Hellwig wrote:
> The DMA API generally relies on a struct device to work properly, and
> only barely works without one for legacy reasons. Pass the easily
> available struct device from the platform_device to remedy this.
>
> Also use the proper Kconfig symbol to check for DMA API availability.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> drivers/net/caif/caif_spi.c | 30 ++++++++++++++++--------------
> 1 file changed, 16 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/net/caif/caif_spi.c b/drivers/net/caif/caif_spi.c
> index d28a1398c091..b7f3e263b57c 100644
> --- a/drivers/net/caif/caif_spi.c
> +++ b/drivers/net/caif/caif_spi.c
> @@ -73,35 +73,37 @@ MODULE_PARM_DESC(spi_down_tail_align, "SPI downlink tail alignment.");
> #define LOW_WATER_MARK 100
> #define HIGH_WATER_MARK (LOW_WATER_MARK*5)
>
> -#ifdef CONFIG_UML
> +#ifdef CONFIG_HAS_DMA
#ifndef, surely?
Robin.
>
> /*
> * We sometimes use UML for debugging, but it cannot handle
> * dma_alloc_coherent so we have to wrap it.
> */
> -static inline void *dma_alloc(dma_addr_t *daddr)
> +static inline void *dma_alloc(struct cfspi *cfspi, dma_addr_t *daddr)
> {
> return kmalloc(SPI_DMA_BUF_LEN, GFP_KERNEL);
> }
>
> -static inline void dma_free(void *cpu_addr, dma_addr_t handle)
> +static inline void dma_free(struct cfspi *cfspi, void *cpu_addr,
> + dma_addr_t handle)
> {
> kfree(cpu_addr);
> }
>
> #else
>
> -static inline void *dma_alloc(dma_addr_t *daddr)
> +static inline void *dma_alloc(struct cfspi *cfspi, dma_addr_t *daddr)
> {
> - return dma_alloc_coherent(NULL, SPI_DMA_BUF_LEN, daddr,
> + return dma_alloc_coherent(&cfspi->pdev->dev, SPI_DMA_BUF_LEN, daddr,
> GFP_KERNEL);
> }
>
> -static inline void dma_free(void *cpu_addr, dma_addr_t handle)
> +static inline void dma_free(struct cfspi *cfspi, void *cpu_addr,
> + dma_addr_t handle)
> {
> - dma_free_coherent(NULL, SPI_DMA_BUF_LEN, cpu_addr, handle);
> + dma_free_coherent(&cfspi->pdev->dev, SPI_DMA_BUF_LEN, cpu_addr, handle);
> }
> -#endif /* CONFIG_UML */
> +#endif /* CONFIG_HAS_DMA */
>
> #ifdef CONFIG_DEBUG_FS
>
> @@ -610,13 +612,13 @@ static int cfspi_init(struct net_device *dev)
> }
>
> /* Allocate DMA buffers. */
> - cfspi->xfer.va_tx[0] = dma_alloc(&cfspi->xfer.pa_tx[0]);
> + cfspi->xfer.va_tx[0] = dma_alloc(cfspi, &cfspi->xfer.pa_tx[0]);
> if (!cfspi->xfer.va_tx[0]) {
> res = -ENODEV;
> goto err_dma_alloc_tx_0;
> }
>
> - cfspi->xfer.va_rx = dma_alloc(&cfspi->xfer.pa_rx);
> + cfspi->xfer.va_rx = dma_alloc(cfspi, &cfspi->xfer.pa_rx);
>
> if (!cfspi->xfer.va_rx) {
> res = -ENODEV;
> @@ -665,9 +667,9 @@ static int cfspi_init(struct net_device *dev)
> return 0;
>
> err_create_wq:
> - dma_free(cfspi->xfer.va_rx, cfspi->xfer.pa_rx);
> + dma_free(cfspi, cfspi->xfer.va_rx, cfspi->xfer.pa_rx);
> err_dma_alloc_rx:
> - dma_free(cfspi->xfer.va_tx[0], cfspi->xfer.pa_tx[0]);
> + dma_free(cfspi, cfspi->xfer.va_tx[0], cfspi->xfer.pa_tx[0]);
> err_dma_alloc_tx_0:
> return res;
> }
> @@ -683,8 +685,8 @@ static void cfspi_uninit(struct net_device *dev)
>
> cfspi->ndev = NULL;
> /* Free DMA buffers. */
> - dma_free(cfspi->xfer.va_rx, cfspi->xfer.pa_rx);
> - dma_free(cfspi->xfer.va_tx[0], cfspi->xfer.pa_tx[0]);
> + dma_free(cfspi, cfspi->xfer.va_rx, cfspi->xfer.pa_rx);
> + dma_free(cfspi, cfspi->xfer.va_tx[0], cfspi->xfer.pa_tx[0]);
> set_bit(SPI_TERMINATE, &cfspi->state);
> wake_up_interruptible(&cfspi->wait);
> destroy_workqueue(cfspi->wq);
>
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH 03/18] net: caif: pass struct device to DMA API functions
2019-02-01 13:53 ` Robin Murphy
@ 2019-02-01 16:10 ` Christoph Hellwig
0 siblings, 0 replies; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01 16:10 UTC (permalink / raw)
To: Robin Murphy
Cc: Christoph Hellwig, John Crispin, Vinod Koul, Dmitry Tarnyagin,
Nicolas Ferre, Sudip Mukherjee, Felipe Balbi, linux-mips,
linux-kernel, dmaengine, netdev, linux-usb, linux-fbdev,
alsa-devel, iommu
On Fri, Feb 01, 2019 at 01:53:09PM +0000, Robin Murphy wrote:
>> #define LOW_WATER_MARK 100
>> #define HIGH_WATER_MARK (LOW_WATER_MARK*5)
>> -#ifdef CONFIG_UML
>> +#ifdef CONFIG_HAS_DMA
>
> #ifndef, surely?
Indeed.
^ permalink raw reply [flat|nested] 41+ messages in thread
* [PATCH 04/18] au1000_eth: pass struct device to DMA API functions
2019-02-01 8:47 don't pass a NULL struct device to DMA API functions Christoph Hellwig
` (2 preceding siblings ...)
2019-02-01 8:47 ` [PATCH 03/18] net: caif: " Christoph Hellwig
@ 2019-02-01 8:47 ` Christoph Hellwig
2019-02-01 8:47 ` [PATCH 05/18] macb_main: " Christoph Hellwig
` (14 subsequent siblings)
18 siblings, 0 replies; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01 8:47 UTC (permalink / raw)
To: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel
Cc: iommu
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/net/ethernet/amd/au1000_eth.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/amd/au1000_eth.c b/drivers/net/ethernet/amd/au1000_eth.c
index e833d1b3fe18..e5073aeea06a 100644
--- a/drivers/net/ethernet/amd/au1000_eth.c
+++ b/drivers/net/ethernet/amd/au1000_eth.c
@@ -1167,7 +1167,7 @@ static int au1000_probe(struct platform_device *pdev)
/* Allocate the data buffers
* Snooping works fine with eth on all au1xxx
*/
- aup->vaddr = (u32)dma_alloc_attrs(NULL, MAX_BUF_SIZE *
+ aup->vaddr = (u32)dma_alloc_attrs(&pdev->dev, MAX_BUF_SIZE *
(NUM_TX_BUFFS + NUM_RX_BUFFS),
&aup->dma_addr, 0,
DMA_ATTR_NON_CONSISTENT);
@@ -1349,7 +1349,7 @@ static int au1000_probe(struct platform_device *pdev)
err_remap2:
iounmap(aup->mac);
err_remap1:
- dma_free_attrs(NULL, MAX_BUF_SIZE * (NUM_TX_BUFFS + NUM_RX_BUFFS),
+ dma_free_attrs(&pdev->dev, MAX_BUF_SIZE * (NUM_TX_BUFFS + NUM_RX_BUFFS),
(void *)aup->vaddr, aup->dma_addr,
DMA_ATTR_NON_CONSISTENT);
err_vaddr:
@@ -1383,7 +1383,7 @@ static int au1000_remove(struct platform_device *pdev)
if (aup->tx_db_inuse[i])
au1000_ReleaseDB(aup, aup->tx_db_inuse[i]);
- dma_free_attrs(NULL, MAX_BUF_SIZE * (NUM_TX_BUFFS + NUM_RX_BUFFS),
+ dma_free_attrs(&pdev->dev, MAX_BUF_SIZE * (NUM_TX_BUFFS + NUM_RX_BUFFS),
(void *)aup->vaddr, aup->dma_addr,
DMA_ATTR_NON_CONSISTENT);
--
2.20.1
^ permalink raw reply related [flat|nested] 41+ messages in thread
* [PATCH 05/18] macb_main: pass struct device to DMA API functions
2019-02-01 8:47 don't pass a NULL struct device to DMA API functions Christoph Hellwig
` (3 preceding siblings ...)
2019-02-01 8:47 ` [PATCH 04/18] au1000_eth: " Christoph Hellwig
@ 2019-02-01 8:47 ` Christoph Hellwig
2019-02-01 13:34 ` Nicolas.Ferre
2019-02-01 8:47 ` [PATCH 06/18] lantiq_etop: " Christoph Hellwig
` (13 subsequent siblings)
18 siblings, 1 reply; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01 8:47 UTC (permalink / raw)
To: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel
Cc: iommu
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/net/ethernet/cadence/macb_main.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index 2b2882615e8b..61a27963f1d1 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -3673,9 +3673,9 @@ static netdev_tx_t at91ether_start_xmit(struct sk_buff *skb,
/* Store packet information (to free when Tx completed) */
lp->skb = skb;
lp->skb_length = skb->len;
- lp->skb_physaddr = dma_map_single(NULL, skb->data, skb->len,
- DMA_TO_DEVICE);
- if (dma_mapping_error(NULL, lp->skb_physaddr)) {
+ lp->skb_physaddr = dma_map_single(&lp->pdev->dev, skb->data,
+ skb->len, DMA_TO_DEVICE);
+ if (dma_mapping_error(&lp->pdev->dev, lp->skb_physaddr)) {
dev_kfree_skb_any(skb);
dev->stats.tx_dropped++;
netdev_err(dev, "%s: DMA mapping error\n", __func__);
@@ -3765,7 +3765,7 @@ static irqreturn_t at91ether_interrupt(int irq, void *dev_id)
if (lp->skb) {
dev_kfree_skb_irq(lp->skb);
lp->skb = NULL;
- dma_unmap_single(NULL, lp->skb_physaddr,
+ dma_unmap_single(&lp->pdev->dev, lp->skb_physaddr,
lp->skb_length, DMA_TO_DEVICE);
dev->stats.tx_packets++;
dev->stats.tx_bytes += lp->skb_length;
--
2.20.1
^ permalink raw reply related [flat|nested] 41+ messages in thread
* Re: [PATCH 05/18] macb_main: pass struct device to DMA API functions
2019-02-01 8:47 ` [PATCH 05/18] macb_main: " Christoph Hellwig
@ 2019-02-01 13:34 ` Nicolas.Ferre
0 siblings, 0 replies; 41+ messages in thread
From: Nicolas.Ferre @ 2019-02-01 13:34 UTC (permalink / raw)
To: hch, john, vkoul, dmitry.tarnyagin, sudipm.mukherjee, balbi,
linux-mips, linux-kernel, dmaengine, netdev, linux-usb,
linux-fbdev, alsa-devel
Cc: iommu
On 01/02/2019 at 09:47, Christoph Hellwig wrote:
> The DMA API generally relies on a struct device to work properly, and
> only barely works without one for legacy reasons. Pass the easily
> available struct device from the platform_device to remedy this.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
> ---
> drivers/net/ethernet/cadence/macb_main.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
> index 2b2882615e8b..61a27963f1d1 100644
> --- a/drivers/net/ethernet/cadence/macb_main.c
> +++ b/drivers/net/ethernet/cadence/macb_main.c
> @@ -3673,9 +3673,9 @@ static netdev_tx_t at91ether_start_xmit(struct sk_buff *skb,
> /* Store packet information (to free when Tx completed) */
> lp->skb = skb;
> lp->skb_length = skb->len;
> - lp->skb_physaddr = dma_map_single(NULL, skb->data, skb->len,
> - DMA_TO_DEVICE);
> - if (dma_mapping_error(NULL, lp->skb_physaddr)) {
> + lp->skb_physaddr = dma_map_single(&lp->pdev->dev, skb->data,
> + skb->len, DMA_TO_DEVICE);
> + if (dma_mapping_error(&lp->pdev->dev, lp->skb_physaddr)) {
> dev_kfree_skb_any(skb);
> dev->stats.tx_dropped++;
> netdev_err(dev, "%s: DMA mapping error\n", __func__);
> @@ -3765,7 +3765,7 @@ static irqreturn_t at91ether_interrupt(int irq, void *dev_id)
> if (lp->skb) {
> dev_kfree_skb_irq(lp->skb);
> lp->skb = NULL;
> - dma_unmap_single(NULL, lp->skb_physaddr,
> + dma_unmap_single(&lp->pdev->dev, lp->skb_physaddr,
> lp->skb_length, DMA_TO_DEVICE);
> dev->stats.tx_packets++;
> dev->stats.tx_bytes += lp->skb_length;
>
--
Nicolas Ferre
^ permalink raw reply [flat|nested] 41+ messages in thread
* [PATCH 06/18] lantiq_etop: pass struct device to DMA API functions
2019-02-01 8:47 don't pass a NULL struct device to DMA API functions Christoph Hellwig
` (4 preceding siblings ...)
2019-02-01 8:47 ` [PATCH 05/18] macb_main: " Christoph Hellwig
@ 2019-02-01 8:47 ` Christoph Hellwig
2019-02-01 8:47 ` [PATCH 07/18] pxa168_eth: " Christoph Hellwig
` (12 subsequent siblings)
18 siblings, 0 replies; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01 8:47 UTC (permalink / raw)
To: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel
Cc: iommu
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Note this driver seems to lack dma_unmap_* calls entirely, but fixing
that is left for another time.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/net/ethernet/lantiq_etop.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/lantiq_etop.c b/drivers/net/ethernet/lantiq_etop.c
index 32ac9045cdae..f9bb890733b5 100644
--- a/drivers/net/ethernet/lantiq_etop.c
+++ b/drivers/net/ethernet/lantiq_etop.c
@@ -112,10 +112,12 @@ struct ltq_etop_priv {
static int
ltq_etop_alloc_skb(struct ltq_etop_chan *ch)
{
+ struct ltq_etop_priv *priv = netdev_priv(ch->netdev);
+
ch->skb[ch->dma.desc] = netdev_alloc_skb(ch->netdev, MAX_DMA_DATA_LEN);
if (!ch->skb[ch->dma.desc])
return -ENOMEM;
- ch->dma.desc_base[ch->dma.desc].addr = dma_map_single(NULL,
+ ch->dma.desc_base[ch->dma.desc].addr = dma_map_single(&priv->pdev->dev,
ch->skb[ch->dma.desc]->data, MAX_DMA_DATA_LEN,
DMA_FROM_DEVICE);
ch->dma.desc_base[ch->dma.desc].addr =
@@ -487,7 +489,7 @@ ltq_etop_tx(struct sk_buff *skb, struct net_device *dev)
netif_trans_update(dev);
spin_lock_irqsave(&priv->lock, flags);
- desc->addr = ((unsigned int) dma_map_single(NULL, skb->data, len,
+ desc->addr = ((unsigned int) dma_map_single(&priv->pdev->dev, skb->data, len,
DMA_TO_DEVICE)) - byte_offset;
wmb();
desc->ctl = LTQ_DMA_OWN | LTQ_DMA_SOP | LTQ_DMA_EOP |
--
2.20.1
^ permalink raw reply related [flat|nested] 41+ messages in thread
* [PATCH 07/18] pxa168_eth: pass struct device to DMA API functions
2019-02-01 8:47 don't pass a NULL struct device to DMA API functions Christoph Hellwig
` (5 preceding siblings ...)
2019-02-01 8:47 ` [PATCH 06/18] lantiq_etop: " Christoph Hellwig
@ 2019-02-01 8:47 ` Christoph Hellwig
2019-02-01 8:47 ` [PATCH 08/18] moxart_ether: " Christoph Hellwig
` (11 subsequent siblings)
18 siblings, 0 replies; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01 8:47 UTC (permalink / raw)
To: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel
Cc: iommu
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Note that this driver seems to entirely lack dma_map_single error
handling, but that is left for another time.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/net/ethernet/marvell/pxa168_eth.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/marvell/pxa168_eth.c b/drivers/net/ethernet/marvell/pxa168_eth.c
index f8a6d6e3cb7a..35f2142aac5e 100644
--- a/drivers/net/ethernet/marvell/pxa168_eth.c
+++ b/drivers/net/ethernet/marvell/pxa168_eth.c
@@ -201,6 +201,7 @@ struct tx_desc {
};
struct pxa168_eth_private {
+ struct platform_device *pdev;
int port_num; /* User Ethernet port number */
int phy_addr;
int phy_speed;
@@ -331,7 +332,7 @@ static void rxq_refill(struct net_device *dev)
used_rx_desc = pep->rx_used_desc_q;
p_used_rx_desc = &pep->p_rx_desc_area[used_rx_desc];
size = skb_end_pointer(skb) - skb->data;
- p_used_rx_desc->buf_ptr = dma_map_single(NULL,
+ p_used_rx_desc->buf_ptr = dma_map_single(&pep->pdev->dev,
skb->data,
size,
DMA_FROM_DEVICE);
@@ -743,7 +744,7 @@ static int txq_reclaim(struct net_device *dev, int force)
netdev_err(dev, "Error in TX\n");
dev->stats.tx_errors++;
}
- dma_unmap_single(NULL, addr, count, DMA_TO_DEVICE);
+ dma_unmap_single(&pep->pdev->dev, addr, count, DMA_TO_DEVICE);
if (skb)
dev_kfree_skb_irq(skb);
released++;
@@ -805,7 +806,7 @@ static int rxq_process(struct net_device *dev, int budget)
if (rx_next_curr_desc == rx_used_desc)
pep->rx_resource_err = 1;
pep->rx_desc_count--;
- dma_unmap_single(NULL, rx_desc->buf_ptr,
+ dma_unmap_single(&pep->pdev->dev, rx_desc->buf_ptr,
rx_desc->buf_size,
DMA_FROM_DEVICE);
received_packets++;
@@ -1274,7 +1275,8 @@ pxa168_eth_start_xmit(struct sk_buff *skb, struct net_device *dev)
length = skb->len;
pep->tx_skb[tx_index] = skb;
desc->byte_cnt = length;
- desc->buf_ptr = dma_map_single(NULL, skb->data, length, DMA_TO_DEVICE);
+ desc->buf_ptr = dma_map_single(&pep->pdev->dev, skb->data, length,
+ DMA_TO_DEVICE);
skb_tx_timestamp(skb);
@@ -1528,6 +1530,7 @@ static int pxa168_eth_probe(struct platform_device *pdev)
if (err)
goto err_free_mdio;
+ pep->pdev = pdev;
SET_NETDEV_DEV(dev, &pdev->dev);
pxa168_init_hw(pep);
err = register_netdev(dev);
--
2.20.1
^ permalink raw reply related [flat|nested] 41+ messages in thread
* [PATCH 08/18] moxart_ether: pass struct device to DMA API functions
2019-02-01 8:47 don't pass a NULL struct device to DMA API functions Christoph Hellwig
` (6 preceding siblings ...)
2019-02-01 8:47 ` [PATCH 07/18] pxa168_eth: " Christoph Hellwig
@ 2019-02-01 8:47 ` Christoph Hellwig
2019-02-01 8:47 ` [PATCH 09/18] meth: " Christoph Hellwig
` (10 subsequent siblings)
18 siblings, 0 replies; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01 8:47 UTC (permalink / raw)
To: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel
Cc: iommu
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/net/ethernet/moxa/moxart_ether.c | 11 +++++++----
drivers/net/ethernet/moxa/moxart_ether.h | 1 +
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/moxa/moxart_ether.c b/drivers/net/ethernet/moxa/moxart_ether.c
index b34055ac476f..00dec0ffb11b 100644
--- a/drivers/net/ethernet/moxa/moxart_ether.c
+++ b/drivers/net/ethernet/moxa/moxart_ether.c
@@ -81,11 +81,13 @@ static void moxart_mac_free_memory(struct net_device *ndev)
priv->rx_buf_size, DMA_FROM_DEVICE);
if (priv->tx_desc_base)
- dma_free_coherent(NULL, TX_REG_DESC_SIZE * TX_DESC_NUM,
+ dma_free_coherent(&priv->pdev->dev,
+ TX_REG_DESC_SIZE * TX_DESC_NUM,
priv->tx_desc_base, priv->tx_base);
if (priv->rx_desc_base)
- dma_free_coherent(NULL, RX_REG_DESC_SIZE * RX_DESC_NUM,
+ dma_free_coherent(&priv->pdev->dev,
+ RX_REG_DESC_SIZE * RX_DESC_NUM,
priv->rx_desc_base, priv->rx_base);
kfree(priv->tx_buf_base);
@@ -476,6 +478,7 @@ static int moxart_mac_probe(struct platform_device *pdev)
priv = netdev_priv(ndev);
priv->ndev = ndev;
+ priv->pdev = pdev;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
ndev->base_addr = res->start;
@@ -491,7 +494,7 @@ static int moxart_mac_probe(struct platform_device *pdev)
priv->tx_buf_size = TX_BUF_SIZE;
priv->rx_buf_size = RX_BUF_SIZE;
- priv->tx_desc_base = dma_alloc_coherent(NULL, TX_REG_DESC_SIZE *
+ priv->tx_desc_base = dma_alloc_coherent(&pdev->dev, TX_REG_DESC_SIZE *
TX_DESC_NUM, &priv->tx_base,
GFP_DMA | GFP_KERNEL);
if (!priv->tx_desc_base) {
@@ -499,7 +502,7 @@ static int moxart_mac_probe(struct platform_device *pdev)
goto init_fail;
}
- priv->rx_desc_base = dma_alloc_coherent(NULL, RX_REG_DESC_SIZE *
+ priv->rx_desc_base = dma_alloc_coherent(&pdev->dev, RX_REG_DESC_SIZE *
RX_DESC_NUM, &priv->rx_base,
GFP_DMA | GFP_KERNEL);
if (!priv->rx_desc_base) {
diff --git a/drivers/net/ethernet/moxa/moxart_ether.h b/drivers/net/ethernet/moxa/moxart_ether.h
index bee608b547d1..bf4c3029cd0c 100644
--- a/drivers/net/ethernet/moxa/moxart_ether.h
+++ b/drivers/net/ethernet/moxa/moxart_ether.h
@@ -292,6 +292,7 @@
#define LINK_STATUS 0x4
struct moxart_mac_priv_t {
+ struct platform_device *pdev;
void __iomem *base;
unsigned int reg_maccr;
unsigned int reg_imr;
--
2.20.1
^ permalink raw reply related [flat|nested] 41+ messages in thread
* [PATCH 09/18] meth: pass struct device to DMA API functions
2019-02-01 8:47 don't pass a NULL struct device to DMA API functions Christoph Hellwig
` (7 preceding siblings ...)
2019-02-01 8:47 ` [PATCH 08/18] moxart_ether: " Christoph Hellwig
@ 2019-02-01 8:47 ` Christoph Hellwig
2019-02-01 8:47 ` [PATCH 10/18] smc911x: " Christoph Hellwig
` (9 subsequent siblings)
18 siblings, 0 replies; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01 8:47 UTC (permalink / raw)
To: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel
Cc: iommu
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Also use GFP_KERNEL instead of GFP_ATOMIC as the gfp_t for the memory
allocation, as we aren't in interrupt context or under a lock.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/net/ethernet/sgi/meth.c | 25 +++++++++++++++----------
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/sgi/meth.c b/drivers/net/ethernet/sgi/meth.c
index 0e1b7e960b98..67954a9e3675 100644
--- a/drivers/net/ethernet/sgi/meth.c
+++ b/drivers/net/ethernet/sgi/meth.c
@@ -68,6 +68,8 @@ module_param(timeout, int, 0);
* packets in and out, so there is place for a packet
*/
struct meth_private {
+ struct platform_device *pdev;
+
/* in-memory copy of MAC Control register */
u64 mac_ctrl;
@@ -211,8 +213,8 @@ static void meth_check_link(struct net_device *dev)
static int meth_init_tx_ring(struct meth_private *priv)
{
/* Init TX ring */
- priv->tx_ring = dma_alloc_coherent(NULL, TX_RING_BUFFER_SIZE,
- &priv->tx_ring_dma, GFP_ATOMIC);
+ priv->tx_ring = dma_alloc_coherent(&priv->pdev->dev,
+ TX_RING_BUFFER_SIZE, &priv->tx_ring_dma, GFP_KERNEL);
if (!priv->tx_ring)
return -ENOMEM;
@@ -236,7 +238,7 @@ static int meth_init_rx_ring(struct meth_private *priv)
priv->rx_ring[i]=(rx_packet*)(priv->rx_skbs[i]->head);
/* I'll need to re-sync it after each RX */
priv->rx_ring_dmas[i] =
- dma_map_single(NULL, priv->rx_ring[i],
+ dma_map_single(&priv->pdev->dev, priv->rx_ring[i],
METH_RX_BUFF_SIZE, DMA_FROM_DEVICE);
mace->eth.rx_fifo = priv->rx_ring_dmas[i];
}
@@ -253,7 +255,7 @@ static void meth_free_tx_ring(struct meth_private *priv)
dev_kfree_skb(priv->tx_skbs[i]);
priv->tx_skbs[i] = NULL;
}
- dma_free_coherent(NULL, TX_RING_BUFFER_SIZE, priv->tx_ring,
+ dma_free_coherent(&priv->pdev->dev, TX_RING_BUFFER_SIZE, priv->tx_ring,
priv->tx_ring_dma);
}
@@ -263,7 +265,7 @@ static void meth_free_rx_ring(struct meth_private *priv)
int i;
for (i = 0; i < RX_RING_ENTRIES; i++) {
- dma_unmap_single(NULL, priv->rx_ring_dmas[i],
+ dma_unmap_single(&priv->pdev->dev, priv->rx_ring_dmas[i],
METH_RX_BUFF_SIZE, DMA_FROM_DEVICE);
priv->rx_ring[i] = 0;
priv->rx_ring_dmas[i] = 0;
@@ -393,7 +395,8 @@ static void meth_rx(struct net_device* dev, unsigned long int_status)
fifo_rptr = (fifo_rptr - 1) & 0x0f;
}
while (priv->rx_write != fifo_rptr) {
- dma_unmap_single(NULL, priv->rx_ring_dmas[priv->rx_write],
+ dma_unmap_single(&priv->pdev->dev,
+ priv->rx_ring_dmas[priv->rx_write],
METH_RX_BUFF_SIZE, DMA_FROM_DEVICE);
status = priv->rx_ring[priv->rx_write]->status.raw;
#if MFE_DEBUG
@@ -454,7 +457,8 @@ static void meth_rx(struct net_device* dev, unsigned long int_status)
priv->rx_ring[priv->rx_write] = (rx_packet*)skb->head;
priv->rx_ring[priv->rx_write]->status.raw = 0;
priv->rx_ring_dmas[priv->rx_write] =
- dma_map_single(NULL, priv->rx_ring[priv->rx_write],
+ dma_map_single(&priv->pdev->dev,
+ priv->rx_ring[priv->rx_write],
METH_RX_BUFF_SIZE, DMA_FROM_DEVICE);
mace->eth.rx_fifo = priv->rx_ring_dmas[priv->rx_write];
ADVANCE_RX_PTR(priv->rx_write);
@@ -637,7 +641,7 @@ static void meth_tx_1page_prepare(struct meth_private *priv,
}
/* first page */
- catbuf = dma_map_single(NULL, buffer_data, buffer_len,
+ catbuf = dma_map_single(&priv->pdev->dev, buffer_data, buffer_len,
DMA_TO_DEVICE);
desc->data.cat_buf[0].form.start_addr = catbuf >> 3;
desc->data.cat_buf[0].form.len = buffer_len - 1;
@@ -663,12 +667,12 @@ static void meth_tx_2page_prepare(struct meth_private *priv,
}
/* first page */
- catbuf1 = dma_map_single(NULL, buffer1_data, buffer1_len,
+ catbuf1 = dma_map_single(&priv->pdev->dev, buffer1_data, buffer1_len,
DMA_TO_DEVICE);
desc->data.cat_buf[0].form.start_addr = catbuf1 >> 3;
desc->data.cat_buf[0].form.len = buffer1_len - 1;
/* second page */
- catbuf2 = dma_map_single(NULL, buffer2_data, buffer2_len,
+ catbuf2 = dma_map_single(&priv->pdev->dev, buffer2_data, buffer2_len,
DMA_TO_DEVICE);
desc->data.cat_buf[1].form.start_addr = catbuf2 >> 3;
desc->data.cat_buf[1].form.len = buffer2_len - 1;
@@ -840,6 +844,7 @@ static int meth_probe(struct platform_device *pdev)
memcpy(dev->dev_addr, o2meth_eaddr, ETH_ALEN);
priv = netdev_priv(dev);
+ priv->pdev = pdev;
spin_lock_init(&priv->meth_lock);
SET_NETDEV_DEV(dev, &pdev->dev);
--
2.20.1
^ permalink raw reply related [flat|nested] 41+ messages in thread
* [PATCH 10/18] smc911x: pass struct device to DMA API functions
2019-02-01 8:47 don't pass a NULL struct device to DMA API functions Christoph Hellwig
` (8 preceding siblings ...)
2019-02-01 8:47 ` [PATCH 09/18] meth: " Christoph Hellwig
@ 2019-02-01 8:47 ` Christoph Hellwig
2019-02-01 14:14 ` Robin Murphy
2019-02-01 8:47 ` [PATCH 11/18] parport_ip32: " Christoph Hellwig
` (8 subsequent siblings)
18 siblings, 1 reply; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01 8:47 UTC (permalink / raw)
To: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel
Cc: iommu
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/net/ethernet/smsc/smc911x.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/smsc/smc911x.c b/drivers/net/ethernet/smsc/smc911x.c
index 8355dfbb8ec3..b550e624500d 100644
--- a/drivers/net/ethernet/smsc/smc911x.c
+++ b/drivers/net/ethernet/smsc/smc911x.c
@@ -1188,7 +1188,7 @@ smc911x_tx_dma_irq(void *data)
DBG(SMC_DEBUG_TX | SMC_DEBUG_DMA, dev, "TX DMA irq handler\n");
BUG_ON(skb == NULL);
- dma_unmap_single(NULL, tx_dmabuf, tx_dmalen, DMA_TO_DEVICE);
+ dma_unmap_single(lp->dev, tx_dmabuf, tx_dmalen, DMA_TO_DEVICE);
netif_trans_update(dev);
dev_kfree_skb_irq(skb);
lp->current_tx_skb = NULL;
@@ -1219,7 +1219,7 @@ smc911x_rx_dma_irq(void *data)
DBG(SMC_DEBUG_FUNC, dev, "--> %s\n", __func__);
DBG(SMC_DEBUG_RX | SMC_DEBUG_DMA, dev, "RX DMA irq handler\n");
- dma_unmap_single(NULL, rx_dmabuf, rx_dmalen, DMA_FROM_DEVICE);
+ dma_unmap_single(lp->dev, rx_dmabuf, rx_dmalen, DMA_FROM_DEVICE);
BUG_ON(skb == NULL);
lp->current_rx_skb = NULL;
PRINT_PKT(skb->data, skb->len);
--
2.20.1
^ permalink raw reply related [flat|nested] 41+ messages in thread
* Re: [PATCH 10/18] smc911x: pass struct device to DMA API functions
2019-02-01 8:47 ` [PATCH 10/18] smc911x: " Christoph Hellwig
@ 2019-02-01 14:14 ` Robin Murphy
2019-02-01 16:11 ` Christoph Hellwig
0 siblings, 1 reply; 41+ messages in thread
From: Robin Murphy @ 2019-02-01 14:14 UTC (permalink / raw)
To: Christoph Hellwig, John Crispin, Vinod Koul, Dmitry Tarnyagin,
Nicolas Ferre, Sudip Mukherjee, Felipe Balbi, linux-mips,
linux-kernel, dmaengine, netdev, linux-usb, linux-fbdev,
alsa-devel
Cc: iommu
On 01/02/2019 08:47, Christoph Hellwig wrote:
> The DMA API generally relies on a struct device to work properly, and
> only barely works without one for legacy reasons. Pass the easily
> available struct device from the platform_device to remedy this.
Hmm, as far as I'm aware these are PIO chips with external DMA
handshaking, rather than actual DMA masters...
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> drivers/net/ethernet/smsc/smc911x.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/smsc/smc911x.c b/drivers/net/ethernet/smsc/smc911x.c
> index 8355dfbb8ec3..b550e624500d 100644
> --- a/drivers/net/ethernet/smsc/smc911x.c
> +++ b/drivers/net/ethernet/smsc/smc911x.c
> @@ -1188,7 +1188,7 @@ smc911x_tx_dma_irq(void *data)
>
> DBG(SMC_DEBUG_TX | SMC_DEBUG_DMA, dev, "TX DMA irq handler\n");
> BUG_ON(skb == NULL);
> - dma_unmap_single(NULL, tx_dmabuf, tx_dmalen, DMA_TO_DEVICE);
> + dma_unmap_single(lp->dev, tx_dmabuf, tx_dmalen, DMA_TO_DEVICE);
..so while the wrong device is still better than no device at all, this
probably wants lp->txdma->device->dev.
> netif_trans_update(dev);
> dev_kfree_skb_irq(skb);
> lp->current_tx_skb = NULL;
> @@ -1219,7 +1219,7 @@ smc911x_rx_dma_irq(void *data)
>
> DBG(SMC_DEBUG_FUNC, dev, "--> %s\n", __func__);
> DBG(SMC_DEBUG_RX | SMC_DEBUG_DMA, dev, "RX DMA irq handler\n");
> - dma_unmap_single(NULL, rx_dmabuf, rx_dmalen, DMA_FROM_DEVICE);
> + dma_unmap_single(lp->dev, rx_dmabuf, rx_dmalen, DMA_FROM_DEVICE);
And equivalently for rxdma here. However, given that this all seems only
relevant to antique ARCH_PXA platforms which are presumably managing to
work as-is, it's probably not worth tinkering too much. I'd just stick a
note in the commit message that we're still only making these
self-consistent with the existing dma_map_single() calls rather than
necessarily correct.
Robin.
> BUG_ON(skb == NULL);
> lp->current_rx_skb = NULL;
> PRINT_PKT(skb->data, skb->len);
>
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH 10/18] smc911x: pass struct device to DMA API functions
2019-02-01 14:14 ` Robin Murphy
@ 2019-02-01 16:11 ` Christoph Hellwig
0 siblings, 0 replies; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01 16:11 UTC (permalink / raw)
To: Robin Murphy
Cc: Christoph Hellwig, John Crispin, Vinod Koul, Dmitry Tarnyagin,
Nicolas Ferre, Sudip Mukherjee, Felipe Balbi, linux-mips,
linux-kernel, dmaengine, netdev, linux-usb, linux-fbdev,
alsa-devel, iommu
On Fri, Feb 01, 2019 at 02:14:34PM +0000, Robin Murphy wrote:
> And equivalently for rxdma here. However, given that this all seems only
> relevant to antique ARCH_PXA platforms which are presumably managing to
> work as-is, it's probably not worth tinkering too much. I'd just stick a
> note in the commit message that we're still only making these
> self-consistent with the existing dma_map_single() calls rather than
> necessarily correct.
Sounds good.
^ permalink raw reply [flat|nested] 41+ messages in thread
* [PATCH 11/18] parport_ip32: pass struct device to DMA API functions
2019-02-01 8:47 don't pass a NULL struct device to DMA API functions Christoph Hellwig
` (9 preceding siblings ...)
2019-02-01 8:47 ` [PATCH 10/18] smc911x: " Christoph Hellwig
@ 2019-02-01 8:47 ` Christoph Hellwig
2019-02-01 8:47 ` [PATCH 12/18] fotg210-udc: remove a bogus dma_sync_single_for_device call Christoph Hellwig
` (7 subsequent siblings)
18 siblings, 0 replies; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01 8:47 UTC (permalink / raw)
To: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel
Cc: iommu
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/parport/parport_ip32.c | 18 ++++++++++--------
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/parport/parport_ip32.c b/drivers/parport/parport_ip32.c
index 62873070f988..b7a892791c3e 100644
--- a/drivers/parport/parport_ip32.c
+++ b/drivers/parport/parport_ip32.c
@@ -568,6 +568,7 @@ static irqreturn_t parport_ip32_merr_interrupt(int irq, void *dev_id)
/**
* parport_ip32_dma_start - begins a DMA transfer
+ * @p: partport to work on
* @dir: DMA direction: DMA_TO_DEVICE or DMA_FROM_DEVICE
* @addr: pointer to data buffer
* @count: buffer size
@@ -575,8 +576,8 @@ static irqreturn_t parport_ip32_merr_interrupt(int irq, void *dev_id)
* Calls to parport_ip32_dma_start() and parport_ip32_dma_stop() must be
* correctly balanced.
*/
-static int parport_ip32_dma_start(enum dma_data_direction dir,
- void *addr, size_t count)
+static int parport_ip32_dma_start(struct parport *p,
+ enum dma_data_direction dir, void *addr, size_t count)
{
unsigned int limit;
u64 ctrl;
@@ -601,7 +602,7 @@ static int parport_ip32_dma_start(enum dma_data_direction dir,
/* Prepare DMA pointers */
parport_ip32_dma.dir = dir;
- parport_ip32_dma.buf = dma_map_single(NULL, addr, count, dir);
+ parport_ip32_dma.buf = dma_map_single(&p->bus_dev, addr, count, dir);
parport_ip32_dma.len = count;
parport_ip32_dma.next = parport_ip32_dma.buf;
parport_ip32_dma.left = parport_ip32_dma.len;
@@ -625,11 +626,12 @@ static int parport_ip32_dma_start(enum dma_data_direction dir,
/**
* parport_ip32_dma_stop - ends a running DMA transfer
+ * @p: partport to work on
*
* Calls to parport_ip32_dma_start() and parport_ip32_dma_stop() must be
* correctly balanced.
*/
-static void parport_ip32_dma_stop(void)
+static void parport_ip32_dma_stop(struct parport *p)
{
u64 ctx_a;
u64 ctx_b;
@@ -685,8 +687,8 @@ static void parport_ip32_dma_stop(void)
enable_irq(MACEISA_PAR_CTXB_IRQ);
parport_ip32_dma.irq_on = 1;
- dma_unmap_single(NULL, parport_ip32_dma.buf, parport_ip32_dma.len,
- parport_ip32_dma.dir);
+ dma_unmap_single(&p->bus_dev, parport_ip32_dma.buf,
+ parport_ip32_dma.len, parport_ip32_dma.dir);
}
/**
@@ -1445,7 +1447,7 @@ static size_t parport_ip32_fifo_write_block_dma(struct parport *p,
priv->irq_mode = PARPORT_IP32_IRQ_HERE;
- parport_ip32_dma_start(DMA_TO_DEVICE, (void *)buf, len);
+ parport_ip32_dma_start(p, DMA_TO_DEVICE, (void *)buf, len);
reinit_completion(&priv->irq_complete);
parport_ip32_frob_econtrol(p, ECR_DMAEN | ECR_SERVINTR, ECR_DMAEN);
@@ -1461,7 +1463,7 @@ static size_t parport_ip32_fifo_write_block_dma(struct parport *p,
if (ecr & ECR_SERVINTR)
break; /* DMA transfer just finished */
}
- parport_ip32_dma_stop();
+ parport_ip32_dma_stop(p);
written = len - parport_ip32_dma_get_residue();
priv->irq_mode = PARPORT_IP32_IRQ_FWD;
--
2.20.1
^ permalink raw reply related [flat|nested] 41+ messages in thread
* [PATCH 12/18] fotg210-udc: remove a bogus dma_sync_single_for_device call
2019-02-01 8:47 don't pass a NULL struct device to DMA API functions Christoph Hellwig
` (10 preceding siblings ...)
2019-02-01 8:47 ` [PATCH 11/18] parport_ip32: " Christoph Hellwig
@ 2019-02-01 8:47 ` Christoph Hellwig
2019-02-01 13:19 ` Felipe Balbi
2019-02-01 8:47 ` [PATCH 13/18] fotg210-udc: pass struct device to DMA API functions Christoph Hellwig
` (6 subsequent siblings)
18 siblings, 1 reply; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01 8:47 UTC (permalink / raw)
To: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel
Cc: iommu
dma_map_single already transfers ownership to the device.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/usb/gadget/udc/fotg210-udc.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/usb/gadget/udc/fotg210-udc.c b/drivers/usb/gadget/udc/fotg210-udc.c
index bc6abaea907d..fe9cf415f2f1 100644
--- a/drivers/usb/gadget/udc/fotg210-udc.c
+++ b/drivers/usb/gadget/udc/fotg210-udc.c
@@ -356,10 +356,6 @@ static void fotg210_start_dma(struct fotg210_ep *ep,
return;
}
- dma_sync_single_for_device(NULL, d, length,
- ep->dir_in ? DMA_TO_DEVICE :
- DMA_FROM_DEVICE);
-
fotg210_enable_dma(ep, d, length);
/* check if dma is done */
--
2.20.1
^ permalink raw reply related [flat|nested] 41+ messages in thread
* Re: [PATCH 12/18] fotg210-udc: remove a bogus dma_sync_single_for_device call
2019-02-01 8:47 ` [PATCH 12/18] fotg210-udc: remove a bogus dma_sync_single_for_device call Christoph Hellwig
@ 2019-02-01 13:19 ` Felipe Balbi
2019-02-01 16:10 ` Christoph Hellwig
0 siblings, 1 reply; 41+ messages in thread
From: Felipe Balbi @ 2019-02-01 13:19 UTC (permalink / raw)
To: Christoph Hellwig, John Crispin, Vinod Koul, Dmitry Tarnyagin,
Nicolas Ferre, Sudip Mukherjee, linux-mips, linux-kernel,
dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel
Cc: iommu
[-- Attachment #1: Type: text/plain, Size: 988 bytes --]
Christoph Hellwig <hch@lst.de> writes:
> dma_map_single already transfers ownership to the device.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Do you want me to take the USB bits or will you take the entire series?
In case you're taking the entire series:
Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
> ---
> drivers/usb/gadget/udc/fotg210-udc.c | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/usb/gadget/udc/fotg210-udc.c b/drivers/usb/gadget/udc/fotg210-udc.c
> index bc6abaea907d..fe9cf415f2f1 100644
> --- a/drivers/usb/gadget/udc/fotg210-udc.c
> +++ b/drivers/usb/gadget/udc/fotg210-udc.c
> @@ -356,10 +356,6 @@ static void fotg210_start_dma(struct fotg210_ep *ep,
> return;
> }
>
> - dma_sync_single_for_device(NULL, d, length,
> - ep->dir_in ? DMA_TO_DEVICE :
> - DMA_FROM_DEVICE);
> -
> fotg210_enable_dma(ep, d, length);
>
> /* check if dma is done */
> --
> 2.20.1
>
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH 12/18] fotg210-udc: remove a bogus dma_sync_single_for_device call
2019-02-01 13:19 ` Felipe Balbi
@ 2019-02-01 16:10 ` Christoph Hellwig
2019-02-11 13:12 ` Christoph Hellwig
0 siblings, 1 reply; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01 16:10 UTC (permalink / raw)
To: Felipe Balbi
Cc: Christoph Hellwig, John Crispin, Vinod Koul, Dmitry Tarnyagin,
Nicolas Ferre, Sudip Mukherjee, linux-mips, linux-kernel,
dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel, iommu
On Fri, Feb 01, 2019 at 03:19:41PM +0200, Felipe Balbi wrote:
> Christoph Hellwig <hch@lst.de> writes:
>
> > dma_map_single already transfers ownership to the device.
> >
> > Signed-off-by: Christoph Hellwig <hch@lst.de>
>
> Do you want me to take the USB bits or will you take the entire series?
> In case you're taking the entire series:
If you want to take the USB feel free. I just want most of this in
this merge window if possible.
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH 12/18] fotg210-udc: remove a bogus dma_sync_single_for_device call
2019-02-01 16:10 ` Christoph Hellwig
@ 2019-02-11 13:12 ` Christoph Hellwig
2019-02-11 13:30 ` Felipe Balbi
0 siblings, 1 reply; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-11 13:12 UTC (permalink / raw)
To: Felipe Balbi
Cc: Christoph Hellwig, John Crispin, Vinod Koul, Dmitry Tarnyagin,
Nicolas Ferre, Sudip Mukherjee, linux-mips, linux-kernel,
dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel, iommu
On Fri, Feb 01, 2019 at 05:10:26PM +0100, Christoph Hellwig wrote:
> On Fri, Feb 01, 2019 at 03:19:41PM +0200, Felipe Balbi wrote:
> > Christoph Hellwig <hch@lst.de> writes:
> >
> > > dma_map_single already transfers ownership to the device.
> > >
> > > Signed-off-by: Christoph Hellwig <hch@lst.de>
> >
> > Do you want me to take the USB bits or will you take the entire series?
> > In case you're taking the entire series:
>
> If you want to take the USB feel free. I just want most of this in
> this merge window if possible.
I didn't see in the USB tree yet, so please let me know if you want to
take it.
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH 12/18] fotg210-udc: remove a bogus dma_sync_single_for_device call
2019-02-11 13:12 ` Christoph Hellwig
@ 2019-02-11 13:30 ` Felipe Balbi
0 siblings, 0 replies; 41+ messages in thread
From: Felipe Balbi @ 2019-02-11 13:30 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Christoph Hellwig, John Crispin, Vinod Koul, Dmitry Tarnyagin,
Nicolas Ferre, Sudip Mukherjee, linux-mips, linux-kernel,
dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel, iommu
[-- Attachment #1: Type: text/plain, Size: 761 bytes --]
Hi,
Christoph Hellwig <hch@lst.de> writes:
> On Fri, Feb 01, 2019 at 05:10:26PM +0100, Christoph Hellwig wrote:
>> On Fri, Feb 01, 2019 at 03:19:41PM +0200, Felipe Balbi wrote:
>> > Christoph Hellwig <hch@lst.de> writes:
>> >
>> > > dma_map_single already transfers ownership to the device.
>> > >
>> > > Signed-off-by: Christoph Hellwig <hch@lst.de>
>> >
>> > Do you want me to take the USB bits or will you take the entire series?
>> > In case you're taking the entire series:
>>
>> If you want to take the USB feel free. I just want most of this in
>> this merge window if possible.
>
> I didn't see in the USB tree yet, so please let me know if you want to
> take it.
sorry for the delay, just took it to my tree.
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply [flat|nested] 41+ messages in thread
* [PATCH 13/18] fotg210-udc: pass struct device to DMA API functions
2019-02-01 8:47 don't pass a NULL struct device to DMA API functions Christoph Hellwig
` (11 preceding siblings ...)
2019-02-01 8:47 ` [PATCH 12/18] fotg210-udc: remove a bogus dma_sync_single_for_device call Christoph Hellwig
@ 2019-02-01 8:47 ` Christoph Hellwig
2019-02-01 13:20 ` Felipe Balbi
2019-02-01 8:47 ` [PATCH 14/18] da8xx-fb: " Christoph Hellwig
` (5 subsequent siblings)
18 siblings, 1 reply; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01 8:47 UTC (permalink / raw)
To: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel
Cc: iommu
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/usb/gadget/udc/fotg210-udc.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/udc/fotg210-udc.c b/drivers/usb/gadget/udc/fotg210-udc.c
index fe9cf415f2f1..cec49294bac6 100644
--- a/drivers/usb/gadget/udc/fotg210-udc.c
+++ b/drivers/usb/gadget/udc/fotg210-udc.c
@@ -326,6 +326,7 @@ static void fotg210_wait_dma_done(struct fotg210_ep *ep)
static void fotg210_start_dma(struct fotg210_ep *ep,
struct fotg210_request *req)
{
+ struct device *dev = &ep->fotg210->gadget.dev;
dma_addr_t d;
u8 *buffer;
u32 length;
@@ -348,10 +349,10 @@ static void fotg210_start_dma(struct fotg210_ep *ep,
length = req->req.length;
}
- d = dma_map_single(NULL, buffer, length,
+ d = dma_map_single(dev, buffer, length,
ep->dir_in ? DMA_TO_DEVICE : DMA_FROM_DEVICE);
- if (dma_mapping_error(NULL, d)) {
+ if (dma_mapping_error(dev, d)) {
pr_err("dma_mapping_error\n");
return;
}
@@ -366,7 +367,7 @@ static void fotg210_start_dma(struct fotg210_ep *ep,
/* update actual transfer length */
req->req.actual += length;
- dma_unmap_single(NULL, d, length, DMA_TO_DEVICE);
+ dma_unmap_single(dev, d, length, DMA_TO_DEVICE);
}
static void fotg210_ep0_queue(struct fotg210_ep *ep,
--
2.20.1
^ permalink raw reply related [flat|nested] 41+ messages in thread
* Re: [PATCH 13/18] fotg210-udc: pass struct device to DMA API functions
2019-02-01 8:47 ` [PATCH 13/18] fotg210-udc: pass struct device to DMA API functions Christoph Hellwig
@ 2019-02-01 13:20 ` Felipe Balbi
0 siblings, 0 replies; 41+ messages in thread
From: Felipe Balbi @ 2019-02-01 13:20 UTC (permalink / raw)
To: Christoph Hellwig, John Crispin, Vinod Koul, Dmitry Tarnyagin,
Nicolas Ferre, Sudip Mukherjee, linux-mips, linux-kernel,
dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel
Cc: iommu
[-- Attachment #1: Type: text/plain, Size: 420 bytes --]
Christoph Hellwig <hch@lst.de> writes:
> The DMA API generally relies on a struct device to work properly, and
> only barely works without one for legacy reasons. Pass the easily
> available struct device from the platform_device to remedy this.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
In case you're taking the entire series:
Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply [flat|nested] 41+ messages in thread
* [PATCH 14/18] da8xx-fb: pass struct device to DMA API functions
2019-02-01 8:47 don't pass a NULL struct device to DMA API functions Christoph Hellwig
` (12 preceding siblings ...)
2019-02-01 8:47 ` [PATCH 13/18] fotg210-udc: pass struct device to DMA API functions Christoph Hellwig
@ 2019-02-01 8:47 ` Christoph Hellwig
2019-02-01 8:47 ` [PATCH 15/18] gbefb: switch to managed version of the DMA allocator Christoph Hellwig
` (4 subsequent siblings)
18 siblings, 0 replies; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01 8:47 UTC (permalink / raw)
To: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel
Cc: iommu
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/video/fbdev/da8xx-fb.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/video/fbdev/da8xx-fb.c b/drivers/video/fbdev/da8xx-fb.c
index 43f2a4816860..ec62274b914b 100644
--- a/drivers/video/fbdev/da8xx-fb.c
+++ b/drivers/video/fbdev/da8xx-fb.c
@@ -1097,9 +1097,9 @@ static int fb_remove(struct platform_device *dev)
unregister_framebuffer(info);
fb_dealloc_cmap(&info->cmap);
- dma_free_coherent(NULL, PALETTE_SIZE, par->v_palette_base,
+ dma_free_coherent(par->dev, PALETTE_SIZE, par->v_palette_base,
par->p_palette_base);
- dma_free_coherent(NULL, par->vram_size, par->vram_virt,
+ dma_free_coherent(par->dev, par->vram_size, par->vram_virt,
par->vram_phys);
pm_runtime_put_sync(&dev->dev);
pm_runtime_disable(&dev->dev);
@@ -1425,7 +1425,7 @@ static int fb_probe(struct platform_device *device)
par->vram_size = roundup(par->vram_size/8, ulcm);
par->vram_size = par->vram_size * LCD_NUM_BUFFERS;
- par->vram_virt = dma_alloc_coherent(NULL,
+ par->vram_virt = dma_alloc_coherent(par->dev,
par->vram_size,
&par->vram_phys,
GFP_KERNEL | GFP_DMA);
@@ -1446,7 +1446,7 @@ static int fb_probe(struct platform_device *device)
da8xx_fb_fix.line_length - 1;
/* allocate palette buffer */
- par->v_palette_base = dma_alloc_coherent(NULL, PALETTE_SIZE,
+ par->v_palette_base = dma_alloc_coherent(par->dev, PALETTE_SIZE,
&par->p_palette_base,
GFP_KERNEL | GFP_DMA);
if (!par->v_palette_base) {
@@ -1532,11 +1532,12 @@ static int fb_probe(struct platform_device *device)
fb_dealloc_cmap(&da8xx_fb_info->cmap);
err_release_pl_mem:
- dma_free_coherent(NULL, PALETTE_SIZE, par->v_palette_base,
+ dma_free_coherent(par->dev, PALETTE_SIZE, par->v_palette_base,
par->p_palette_base);
err_release_fb_mem:
- dma_free_coherent(NULL, par->vram_size, par->vram_virt, par->vram_phys);
+ dma_free_coherent(par->dev, par->vram_size, par->vram_virt,
+ par->vram_phys);
err_release_fb:
framebuffer_release(da8xx_fb_info);
--
2.20.1
^ permalink raw reply related [flat|nested] 41+ messages in thread
* [PATCH 15/18] gbefb: switch to managed version of the DMA allocator
2019-02-01 8:47 don't pass a NULL struct device to DMA API functions Christoph Hellwig
` (13 preceding siblings ...)
2019-02-01 8:47 ` [PATCH 14/18] da8xx-fb: " Christoph Hellwig
@ 2019-02-01 8:47 ` Christoph Hellwig
2019-02-01 8:47 ` [PATCH 16/18] pxa3xx-gcu: pass struct device to dma_mmap_coherent Christoph Hellwig
` (3 subsequent siblings)
18 siblings, 0 replies; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01 8:47 UTC (permalink / raw)
To: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel
Cc: iommu
gbefb uses managed resources, so it should do the same for DMA
allocations.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/video/fbdev/gbefb.c | 24 ++++++++----------------
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git a/drivers/video/fbdev/gbefb.c b/drivers/video/fbdev/gbefb.c
index 1a242b1338e9..3fcb33232ba3 100644
--- a/drivers/video/fbdev/gbefb.c
+++ b/drivers/video/fbdev/gbefb.c
@@ -1162,9 +1162,9 @@ static int gbefb_probe(struct platform_device *p_dev)
}
gbe_revision = gbe->ctrlstat & 15;
- gbe_tiles.cpu =
- dma_alloc_coherent(NULL, GBE_TLB_SIZE * sizeof(uint16_t),
- &gbe_tiles.dma, GFP_KERNEL);
+ gbe_tiles.cpu = dmam_alloc_coherent(&p_dev->dev,
+ GBE_TLB_SIZE * sizeof(uint16_t),
+ &gbe_tiles.dma, GFP_KERNEL);
if (!gbe_tiles.cpu) {
printk(KERN_ERR "gbefb: couldn't allocate tiles table\n");
ret = -ENOMEM;
@@ -1178,19 +1178,20 @@ static int gbefb_probe(struct platform_device *p_dev)
if (!gbe_mem) {
printk(KERN_ERR "gbefb: couldn't map framebuffer\n");
ret = -ENOMEM;
- goto out_tiles_free;
+ goto out_release_mem_region;
}
gbe_dma_addr = 0;
} else {
/* try to allocate memory with the classical allocator
* this has high chance to fail on low memory machines */
- gbe_mem = dma_alloc_wc(NULL, gbe_mem_size, &gbe_dma_addr,
- GFP_KERNEL);
+ gbe_mem = dmam_alloc_attrs(&p_dev->dev, gbe_mem_size,
+ &gbe_dma_addr, GFP_KERNEL,
+ DMA_ATTR_WRITE_COMBINE);
if (!gbe_mem) {
printk(KERN_ERR "gbefb: couldn't allocate framebuffer memory\n");
ret = -ENOMEM;
- goto out_tiles_free;
+ goto out_release_mem_region;
}
gbe_mem_phys = (unsigned long) gbe_dma_addr;
@@ -1237,11 +1238,6 @@ static int gbefb_probe(struct platform_device *p_dev)
out_gbe_unmap:
arch_phys_wc_del(par->wc_cookie);
- if (gbe_dma_addr)
- dma_free_wc(NULL, gbe_mem_size, gbe_mem, gbe_mem_phys);
-out_tiles_free:
- dma_free_coherent(NULL, GBE_TLB_SIZE * sizeof(uint16_t),
- (void *)gbe_tiles.cpu, gbe_tiles.dma);
out_release_mem_region:
release_mem_region(GBE_BASE, sizeof(struct sgi_gbe));
out_release_framebuffer:
@@ -1258,10 +1254,6 @@ static int gbefb_remove(struct platform_device* p_dev)
unregister_framebuffer(info);
gbe_turn_off();
arch_phys_wc_del(par->wc_cookie);
- if (gbe_dma_addr)
- dma_free_wc(NULL, gbe_mem_size, gbe_mem, gbe_mem_phys);
- dma_free_coherent(NULL, GBE_TLB_SIZE * sizeof(uint16_t),
- (void *)gbe_tiles.cpu, gbe_tiles.dma);
release_mem_region(GBE_BASE, sizeof(struct sgi_gbe));
gbefb_remove_sysfs(&p_dev->dev);
framebuffer_release(info);
--
2.20.1
^ permalink raw reply related [flat|nested] 41+ messages in thread
* [PATCH 16/18] pxa3xx-gcu: pass struct device to dma_mmap_coherent
2019-02-01 8:47 don't pass a NULL struct device to DMA API functions Christoph Hellwig
` (14 preceding siblings ...)
2019-02-01 8:47 ` [PATCH 15/18] gbefb: switch to managed version of the DMA allocator Christoph Hellwig
@ 2019-02-01 8:47 ` Christoph Hellwig
2019-02-01 8:48 ` [PATCH 17/18] ALSA: hal2: pass struct device to DMA API functions Christoph Hellwig
` (2 subsequent siblings)
18 siblings, 0 replies; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01 8:47 UTC (permalink / raw)
To: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel
Cc: iommu
Just like we do for all other DMA operations.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/video/fbdev/pxa3xx-gcu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/pxa3xx-gcu.c b/drivers/video/fbdev/pxa3xx-gcu.c
index 69cfb337c857..047a2fa4b87e 100644
--- a/drivers/video/fbdev/pxa3xx-gcu.c
+++ b/drivers/video/fbdev/pxa3xx-gcu.c
@@ -96,6 +96,7 @@ struct pxa3xx_gcu_batch {
};
struct pxa3xx_gcu_priv {
+ struct device *dev;
void __iomem *mmio_base;
struct clk *clk;
struct pxa3xx_gcu_shared *shared;
@@ -493,7 +494,7 @@ pxa3xx_gcu_mmap(struct file *file, struct vm_area_struct *vma)
if (size != SHARED_SIZE)
return -EINVAL;
- return dma_mmap_coherent(NULL, vma,
+ return dma_mmap_coherent(priv->dev, vma,
priv->shared, priv->shared_phys, size);
case SHARED_SIZE >> PAGE_SHIFT:
@@ -670,6 +671,7 @@ static int pxa3xx_gcu_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, priv);
priv->resource_mem = r;
+ priv->dev = dev;
pxa3xx_gcu_reset(priv);
pxa3xx_gcu_init_debug_timer(priv);
--
2.20.1
^ permalink raw reply related [flat|nested] 41+ messages in thread
* [PATCH 17/18] ALSA: hal2: pass struct device to DMA API functions
2019-02-01 8:47 don't pass a NULL struct device to DMA API functions Christoph Hellwig
` (15 preceding siblings ...)
2019-02-01 8:47 ` [PATCH 16/18] pxa3xx-gcu: pass struct device to dma_mmap_coherent Christoph Hellwig
@ 2019-02-01 8:48 ` Christoph Hellwig
2019-02-01 13:12 ` [alsa-devel] " Takashi Iwai
2019-02-01 8:48 ` [PATCH 18/18] ALSA: " Christoph Hellwig
2019-02-01 13:16 ` [alsa-devel] don't pass a NULL " Takashi Iwai
18 siblings, 1 reply; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01 8:48 UTC (permalink / raw)
To: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel
Cc: iommu
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
sound/mips/hal2.c | 31 +++++++++++++++++--------------
1 file changed, 17 insertions(+), 14 deletions(-)
diff --git a/sound/mips/hal2.c b/sound/mips/hal2.c
index a4ed54aeaf1d..d63e1565b62b 100644
--- a/sound/mips/hal2.c
+++ b/sound/mips/hal2.c
@@ -454,21 +454,22 @@ static inline void hal2_stop_adc(struct snd_hal2 *hal2)
hal2->adc.pbus.pbus->pbdma_ctrl = HPC3_PDMACTRL_LD;
}
-static int hal2_alloc_dmabuf(struct hal2_codec *codec)
+static int hal2_alloc_dmabuf(struct snd_hal2 *hal2, struct hal2_codec *codec)
{
+ struct device *dev = hal2->card->dev;
struct hal2_desc *desc;
dma_addr_t desc_dma, buffer_dma;
int count = H2_BUF_SIZE / H2_BLOCK_SIZE;
int i;
- codec->buffer = dma_alloc_attrs(NULL, H2_BUF_SIZE, &buffer_dma,
+ codec->buffer = dma_alloc_attrs(dev, H2_BUF_SIZE, &buffer_dma,
GFP_KERNEL, DMA_ATTR_NON_CONSISTENT);
if (!codec->buffer)
return -ENOMEM;
- desc = dma_alloc_attrs(NULL, count * sizeof(struct hal2_desc),
+ desc = dma_alloc_attrs(dev, count * sizeof(struct hal2_desc),
&desc_dma, GFP_KERNEL, DMA_ATTR_NON_CONSISTENT);
if (!desc) {
- dma_free_attrs(NULL, H2_BUF_SIZE, codec->buffer, buffer_dma,
+ dma_free_attrs(dev, H2_BUF_SIZE, codec->buffer, buffer_dma,
DMA_ATTR_NON_CONSISTENT);
return -ENOMEM;
}
@@ -482,17 +483,19 @@ static int hal2_alloc_dmabuf(struct hal2_codec *codec)
desc_dma : desc_dma + (i + 1) * sizeof(struct hal2_desc);
desc++;
}
- dma_cache_sync(NULL, codec->desc, count * sizeof(struct hal2_desc),
+ dma_cache_sync(dev, codec->desc, count * sizeof(struct hal2_desc),
DMA_TO_DEVICE);
codec->desc_count = count;
return 0;
}
-static void hal2_free_dmabuf(struct hal2_codec *codec)
+static void hal2_free_dmabuf(struct snd_hal2 *hal2, struct hal2_codec *codec)
{
- dma_free_attrs(NULL, codec->desc_count * sizeof(struct hal2_desc),
+ struct device *dev = hal2->card->dev;
+
+ dma_free_attrs(dev, codec->desc_count * sizeof(struct hal2_desc),
codec->desc, codec->desc_dma, DMA_ATTR_NON_CONSISTENT);
- dma_free_attrs(NULL, H2_BUF_SIZE, codec->buffer, codec->buffer_dma,
+ dma_free_attrs(dev, H2_BUF_SIZE, codec->buffer, codec->buffer_dma,
DMA_ATTR_NON_CONSISTENT);
}
@@ -540,7 +543,7 @@ static int hal2_playback_open(struct snd_pcm_substream *substream)
runtime->hw = hal2_pcm_hw;
- err = hal2_alloc_dmabuf(&hal2->dac);
+ err = hal2_alloc_dmabuf(hal2, &hal2->dac);
if (err)
return err;
return 0;
@@ -550,7 +553,7 @@ static int hal2_playback_close(struct snd_pcm_substream *substream)
{
struct snd_hal2 *hal2 = snd_pcm_substream_chip(substream);
- hal2_free_dmabuf(&hal2->dac);
+ hal2_free_dmabuf(hal2, &hal2->dac);
return 0;
}
@@ -606,7 +609,7 @@ static void hal2_playback_transfer(struct snd_pcm_substream *substream,
unsigned char *buf = hal2->dac.buffer + rec->hw_data;
memcpy(buf, substream->runtime->dma_area + rec->sw_data, bytes);
- dma_cache_sync(NULL, buf, bytes, DMA_TO_DEVICE);
+ dma_cache_sync(hal2->card->dev, buf, bytes, DMA_TO_DEVICE);
}
@@ -629,7 +632,7 @@ static int hal2_capture_open(struct snd_pcm_substream *substream)
runtime->hw = hal2_pcm_hw;
- err = hal2_alloc_dmabuf(adc);
+ err = hal2_alloc_dmabuf(hal2, adc);
if (err)
return err;
return 0;
@@ -639,7 +642,7 @@ static int hal2_capture_close(struct snd_pcm_substream *substream)
{
struct snd_hal2 *hal2 = snd_pcm_substream_chip(substream);
- hal2_free_dmabuf(&hal2->adc);
+ hal2_free_dmabuf(hal2, &hal2->adc);
return 0;
}
@@ -694,7 +697,7 @@ static void hal2_capture_transfer(struct snd_pcm_substream *substream,
struct snd_hal2 *hal2 = snd_pcm_substream_chip(substream);
unsigned char *buf = hal2->adc.buffer + rec->hw_data;
- dma_cache_sync(NULL, buf, bytes, DMA_FROM_DEVICE);
+ dma_cache_sync(hal2->card->dev, buf, bytes, DMA_FROM_DEVICE);
memcpy(substream->runtime->dma_area + rec->sw_data, buf, bytes);
}
--
2.20.1
^ permalink raw reply related [flat|nested] 41+ messages in thread
* Re: [alsa-devel] [PATCH 17/18] ALSA: hal2: pass struct device to DMA API functions
2019-02-01 8:48 ` [PATCH 17/18] ALSA: hal2: pass struct device to DMA API functions Christoph Hellwig
@ 2019-02-01 13:12 ` Takashi Iwai
2019-02-01 16:09 ` Christoph Hellwig
0 siblings, 1 reply; 41+ messages in thread
From: Takashi Iwai @ 2019-02-01 13:12 UTC (permalink / raw)
To: Christoph Hellwig
Cc: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel, iommu
On Fri, 01 Feb 2019 09:48:00 +0100,
Christoph Hellwig wrote:
>
> The DMA API generally relies on a struct device to work properly, and
> only barely works without one for legacy reasons. Pass the easily
> available struct device from the platform_device to remedy this.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Looks good to me:
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Shall I take this one through sound git tree or all through yours?
thanks,
Takashi
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [alsa-devel] [PATCH 17/18] ALSA: hal2: pass struct device to DMA API functions
2019-02-01 13:12 ` [alsa-devel] " Takashi Iwai
@ 2019-02-01 16:09 ` Christoph Hellwig
2019-02-01 16:17 ` Takashi Iwai
0 siblings, 1 reply; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01 16:09 UTC (permalink / raw)
To: Takashi Iwai
Cc: Christoph Hellwig, John Crispin, Vinod Koul, Dmitry Tarnyagin,
Nicolas Ferre, Sudip Mukherjee, Felipe Balbi, linux-mips,
linux-kernel, dmaengine, netdev, linux-usb, linux-fbdev,
alsa-devel, iommu
On Fri, Feb 01, 2019 at 02:12:45PM +0100, Takashi Iwai wrote:
> Shall I take this one through sound git tree or all through yours?
Feel free to merge the sound bits through your tree!
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [alsa-devel] [PATCH 17/18] ALSA: hal2: pass struct device to DMA API functions
2019-02-01 16:09 ` Christoph Hellwig
@ 2019-02-01 16:17 ` Takashi Iwai
0 siblings, 0 replies; 41+ messages in thread
From: Takashi Iwai @ 2019-02-01 16:17 UTC (permalink / raw)
To: Christoph Hellwig
Cc: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel, iommu
On Fri, 01 Feb 2019 17:09:06 +0100,
Christoph Hellwig wrote:
>
> On Fri, Feb 01, 2019 at 02:12:45PM +0100, Takashi Iwai wrote:
> > Shall I take this one through sound git tree or all through yours?
>
> Feel free to merge the sound bits through your tree!
Alright, merged both patches 17 and 18 now.
thanks,
Takashi
^ permalink raw reply [flat|nested] 41+ messages in thread
* [PATCH 18/18] ALSA: pass struct device to DMA API functions
2019-02-01 8:47 don't pass a NULL struct device to DMA API functions Christoph Hellwig
` (16 preceding siblings ...)
2019-02-01 8:48 ` [PATCH 17/18] ALSA: hal2: pass struct device to DMA API functions Christoph Hellwig
@ 2019-02-01 8:48 ` Christoph Hellwig
2019-02-01 13:13 ` [alsa-devel] " Takashi Iwai
2019-02-01 13:16 ` [alsa-devel] don't pass a NULL " Takashi Iwai
18 siblings, 1 reply; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01 8:48 UTC (permalink / raw)
To: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel
Cc: iommu
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Also use GFP_KERNEL instead of GFP_USER as the gfp_t for the memory
allocation, as we should treat this allocation as a normal kernel one.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
sound/mips/sgio2audio.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/sound/mips/sgio2audio.c b/sound/mips/sgio2audio.c
index 3ec9391a4736..53a4ee01c522 100644
--- a/sound/mips/sgio2audio.c
+++ b/sound/mips/sgio2audio.c
@@ -805,7 +805,7 @@ static int snd_sgio2audio_free(struct snd_sgio2audio *chip)
free_irq(snd_sgio2_isr_table[i].irq,
&chip->channel[snd_sgio2_isr_table[i].idx]);
- dma_free_coherent(NULL, MACEISA_RINGBUFFERS_SIZE,
+ dma_free_coherent(chip->card->dev, MACEISA_RINGBUFFERS_SIZE,
chip->ring_base, chip->ring_base_dma);
/* release card data */
@@ -843,8 +843,9 @@ static int snd_sgio2audio_create(struct snd_card *card,
chip->card = card;
- chip->ring_base = dma_alloc_coherent(NULL, MACEISA_RINGBUFFERS_SIZE,
- &chip->ring_base_dma, GFP_USER);
+ chip->ring_base = dma_alloc_coherent(card->dev,
+ MACEISA_RINGBUFFERS_SIZE,
+ &chip->ring_base_dma, GFP_KERNEL);
if (chip->ring_base == NULL) {
printk(KERN_ERR
"sgio2audio: could not allocate ring buffers\n");
--
2.20.1
^ permalink raw reply related [flat|nested] 41+ messages in thread
* Re: [alsa-devel] [PATCH 18/18] ALSA: pass struct device to DMA API functions
2019-02-01 8:48 ` [PATCH 18/18] ALSA: " Christoph Hellwig
@ 2019-02-01 13:13 ` Takashi Iwai
0 siblings, 0 replies; 41+ messages in thread
From: Takashi Iwai @ 2019-02-01 13:13 UTC (permalink / raw)
To: Christoph Hellwig
Cc: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel, iommu
On Fri, 01 Feb 2019 09:48:01 +0100,
Christoph Hellwig wrote:
>
> The DMA API generally relies on a struct device to work properly, and
> only barely works without one for legacy reasons. Pass the easily
> available struct device from the platform_device to remedy this.
>
> Also use GFP_KERNEL instead of GFP_USER as the gfp_t for the memory
> allocation, as we should treat this allocation as a normal kernel one.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
thanks,
Takashi
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [alsa-devel] don't pass a NULL struct device to DMA API functions
2019-02-01 8:47 don't pass a NULL struct device to DMA API functions Christoph Hellwig
` (17 preceding siblings ...)
2019-02-01 8:48 ` [PATCH 18/18] ALSA: " Christoph Hellwig
@ 2019-02-01 13:16 ` Takashi Iwai
2019-02-01 16:09 ` Christoph Hellwig
18 siblings, 1 reply; 41+ messages in thread
From: Takashi Iwai @ 2019-02-01 13:16 UTC (permalink / raw)
To: Christoph Hellwig
Cc: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel, iommu
On Fri, 01 Feb 2019 09:47:43 +0100,
Christoph Hellwig wrote:
>
> We still have a few drivers which pass a NULL struct device pointer
> to DMA API functions, which generally is a bad idea as the API
> implementations rely on the device not only for ops selection, but
> also the dma mask and various other attributes.
>
> This series contains all easy conversions to pass a struct device,
> besides that there also is some arch code that needs separate handling,
> a driver that should not use the DMA API at all, and one that is
> a complete basket case to be deal with separately.
Actually there are a bunch of ISA sound drivers that still call
allocators with NULL device.
The patch below should address it, although it's only compile-tested.
thanks,
Takashi
-- 8< --
From: Takashi Iwai <tiwai@suse.de>
Subject: [PATCH] ALSA: isa: Avoid passing NULL to memory allocators
We used to pass NULL to memory allocators for ISA devices due to
historical reasons. But we prefer rather a proper device object to be
assigned, so let's fix it by replacing snd_dma_isa_data() call with
card->dev reference, and kill snd_dma_isa_data() definition.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
Documentation/sound/kernel-api/writing-an-alsa-driver.rst | 10 +++++-----
include/sound/memalloc.h | 1 -
sound/isa/ad1816a/ad1816a_lib.c | 2 +-
sound/isa/cmi8330.c | 2 +-
sound/isa/es1688/es1688_lib.c | 2 +-
sound/isa/es18xx.c | 2 +-
sound/isa/gus/gus_pcm.c | 4 ++--
sound/isa/sb/sb16_main.c | 2 +-
sound/isa/sb/sb8_main.c | 2 +-
sound/isa/sscape.c | 7 ++++---
sound/isa/wss/wss_lib.c | 2 +-
11 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst
index 7c2f2032d30a..6b154dbb02cc 100644
--- a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst
+++ b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst
@@ -3520,14 +3520,14 @@ allocator will try to get an area as large as possible within the
given size.
The second argument (type) and the third argument (device pointer) are
-dependent on the bus. In the case of the ISA bus, pass
-:c:func:`snd_dma_isa_data()` as the third argument with
+dependent on the bus. For normal devices, pass the device pointer
+(typically identical as ``card->dev``) to the third argument with
``SNDRV_DMA_TYPE_DEV`` type. For the continuous buffer unrelated to the
bus can be pre-allocated with ``SNDRV_DMA_TYPE_CONTINUOUS`` type and the
``snd_dma_continuous_data(GFP_KERNEL)`` device pointer, where
-``GFP_KERNEL`` is the kernel allocation flag to use. For the PCI
-scatter-gather buffers, use ``SNDRV_DMA_TYPE_DEV_SG`` with
-``snd_dma_pci_data(pci)`` (see the `Non-Contiguous Buffers`_
+``GFP_KERNEL`` is the kernel allocation flag to use. For the
+scatter-gather buffers, use ``SNDRV_DMA_TYPE_DEV_SG`` with the device
+pointer (see the `Non-Contiguous Buffers`_
section).
Once the buffer is pre-allocated, you can use the allocator in the
diff --git a/include/sound/memalloc.h b/include/sound/memalloc.h
index af3fa577fa06..1ac0dd82a916 100644
--- a/include/sound/memalloc.h
+++ b/include/sound/memalloc.h
@@ -37,7 +37,6 @@ struct snd_dma_device {
};
#define snd_dma_pci_data(pci) (&(pci)->dev)
-#define snd_dma_isa_data() NULL
#define snd_dma_continuous_data(x) ((struct device *)(__force unsigned long)(x))
diff --git a/sound/isa/ad1816a/ad1816a_lib.c b/sound/isa/ad1816a/ad1816a_lib.c
index 61e8c7e524db..94b381a78e9e 100644
--- a/sound/isa/ad1816a/ad1816a_lib.c
+++ b/sound/isa/ad1816a/ad1816a_lib.c
@@ -693,7 +693,7 @@ int snd_ad1816a_pcm(struct snd_ad1816a *chip, int device)
snd_ad1816a_init(chip);
snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV,
- snd_dma_isa_data(),
+ chip->card->dev,
64*1024, chip->dma1 > 3 || chip->dma2 > 3 ? 128*1024 : 64*1024);
chip->pcm = pcm;
diff --git a/sound/isa/cmi8330.c b/sound/isa/cmi8330.c
index 7e5aa06414c4..1868b73aa49c 100644
--- a/sound/isa/cmi8330.c
+++ b/sound/isa/cmi8330.c
@@ -470,7 +470,7 @@ static int snd_cmi8330_pcm(struct snd_card *card, struct snd_cmi8330 *chip)
snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_CAPTURE, &chip->streams[SNDRV_PCM_STREAM_CAPTURE].ops);
snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV,
- snd_dma_isa_data(),
+ card->dev,
64*1024, 128*1024);
chip->pcm = pcm;
diff --git a/sound/isa/es1688/es1688_lib.c b/sound/isa/es1688/es1688_lib.c
index 50cdce0e8946..da341969e650 100644
--- a/sound/isa/es1688/es1688_lib.c
+++ b/sound/isa/es1688/es1688_lib.c
@@ -746,7 +746,7 @@ int snd_es1688_pcm(struct snd_card *card, struct snd_es1688 *chip, int device)
chip->pcm = pcm;
snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV,
- snd_dma_isa_data(),
+ card->dev,
64*1024, 64*1024);
return 0;
}
diff --git a/sound/isa/es18xx.c b/sound/isa/es18xx.c
index 77aa9a27fb3b..07abc7f7840c 100644
--- a/sound/isa/es18xx.c
+++ b/sound/isa/es18xx.c
@@ -1717,7 +1717,7 @@ static int snd_es18xx_pcm(struct snd_card *card, int device)
chip->pcm = pcm;
snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV,
- snd_dma_isa_data(),
+ card->dev,
64*1024,
chip->dma1 > 3 || chip->dma2 > 3 ? 128*1024 : 64*1024);
return 0;
diff --git a/sound/isa/gus/gus_pcm.c b/sound/isa/gus/gus_pcm.c
index 131b28997e1d..b9efc6dff45d 100644
--- a/sound/isa/gus/gus_pcm.c
+++ b/sound/isa/gus/gus_pcm.c
@@ -891,7 +891,7 @@ int snd_gf1_pcm_new(struct snd_gus_card *gus, int pcm_dev, int control_index)
for (substream = pcm->streams[SNDRV_PCM_STREAM_PLAYBACK].substream; substream; substream = substream->next)
snd_pcm_lib_preallocate_pages(substream, SNDRV_DMA_TYPE_DEV,
- snd_dma_isa_data(),
+ card->dev,
64*1024, gus->gf1.dma1 > 3 ? 128*1024 : 64*1024);
pcm->info_flags = 0;
@@ -901,7 +901,7 @@ int snd_gf1_pcm_new(struct snd_gus_card *gus, int pcm_dev, int control_index)
if (gus->gf1.dma2 == gus->gf1.dma1)
pcm->info_flags |= SNDRV_PCM_INFO_HALF_DUPLEX;
snd_pcm_lib_preallocate_pages(pcm->streams[SNDRV_PCM_STREAM_CAPTURE].substream,
- SNDRV_DMA_TYPE_DEV, snd_dma_isa_data(),
+ SNDRV_DMA_TYPE_DEV, card->dev,
64*1024, gus->gf1.dma2 > 3 ? 128*1024 : 64*1024);
}
strcpy(pcm->name, pcm->id);
diff --git a/sound/isa/sb/sb16_main.c b/sound/isa/sb/sb16_main.c
index 981d65d122b6..473ec74ae48c 100644
--- a/sound/isa/sb/sb16_main.c
+++ b/sound/isa/sb/sb16_main.c
@@ -889,7 +889,7 @@ int snd_sb16dsp_pcm(struct snd_sb *chip, int device)
}
snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV,
- snd_dma_isa_data(),
+ card->dev,
64*1024, 128*1024);
return 0;
}
diff --git a/sound/isa/sb/sb8_main.c b/sound/isa/sb/sb8_main.c
index 8288fae90085..97645a732a71 100644
--- a/sound/isa/sb/sb8_main.c
+++ b/sound/isa/sb/sb8_main.c
@@ -610,7 +610,7 @@ int snd_sb8dsp_pcm(struct snd_sb *chip, int device)
if (chip->dma8 > 3 || chip->dma16 >= 0)
max_prealloc = 128 * 1024;
snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV,
- snd_dma_isa_data(),
+ card->dev,
64*1024, max_prealloc);
return 0;
diff --git a/sound/isa/sscape.c b/sound/isa/sscape.c
index 733adee5afbf..8181db4db019 100644
--- a/sound/isa/sscape.c
+++ b/sound/isa/sscape.c
@@ -167,12 +167,13 @@ static inline struct soundscape *get_card_soundscape(struct snd_card *c)
* I think this means that the memory has to map to
* contiguous pages of physical memory.
*/
-static struct snd_dma_buffer *get_dmabuf(struct snd_dma_buffer *buf,
+static struct snd_dma_buffer *get_dmabuf(struct soundscape *s,
+ struct snd_dma_buffer *buf,
unsigned long size)
{
if (buf) {
if (snd_dma_alloc_pages_fallback(SNDRV_DMA_TYPE_DEV,
- snd_dma_isa_data(),
+ s->chip->card->dev,
size, buf) < 0) {
snd_printk(KERN_ERR "sscape: Failed to allocate "
"%lu bytes for DMA\n",
@@ -443,7 +444,7 @@ static int upload_dma_data(struct soundscape *s, const unsigned char *data,
int ret;
unsigned char val;
- if (!get_dmabuf(&dma, PAGE_ALIGN(32 * 1024)))
+ if (!get_dmabuf(s, &dma, PAGE_ALIGN(32 * 1024)))
return -ENOMEM;
spin_lock_irqsave(&s->lock, flags);
diff --git a/sound/isa/wss/wss_lib.c b/sound/isa/wss/wss_lib.c
index b11ef97bce1b..0dfb8065b403 100644
--- a/sound/isa/wss/wss_lib.c
+++ b/sound/isa/wss/wss_lib.c
@@ -1942,7 +1942,7 @@ int snd_wss_pcm(struct snd_wss *chip, int device)
strcpy(pcm->name, snd_wss_chip_id(chip));
snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV,
- snd_dma_isa_data(),
+ chip->card->dev,
64*1024, chip->dma1 > 3 || chip->dma2 > 3 ? 128*1024 : 64*1024);
chip->pcm = pcm;
--
2.16.4
^ permalink raw reply related [flat|nested] 41+ messages in thread
* Re: [alsa-devel] don't pass a NULL struct device to DMA API functions
2019-02-01 13:16 ` [alsa-devel] don't pass a NULL " Takashi Iwai
@ 2019-02-01 16:09 ` Christoph Hellwig
2019-02-01 16:18 ` Takashi Iwai
0 siblings, 1 reply; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01 16:09 UTC (permalink / raw)
To: Takashi Iwai
Cc: Christoph Hellwig, John Crispin, Vinod Koul, Dmitry Tarnyagin,
Nicolas Ferre, Sudip Mukherjee, Felipe Balbi, linux-mips,
linux-kernel, dmaengine, netdev, linux-usb, linux-fbdev,
alsa-devel, iommu
On Fri, Feb 01, 2019 at 02:16:08PM +0100, Takashi Iwai wrote:
> Actually there are a bunch of ISA sound drivers that still call
> allocators with NULL device.
>
> The patch below should address it, although it's only compile-tested.
Oh, I missed these "indirect" calls. This looks good to me:
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [alsa-devel] don't pass a NULL struct device to DMA API functions
2019-02-01 16:09 ` Christoph Hellwig
@ 2019-02-01 16:18 ` Takashi Iwai
0 siblings, 0 replies; 41+ messages in thread
From: Takashi Iwai @ 2019-02-01 16:18 UTC (permalink / raw)
To: Christoph Hellwig
Cc: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel, iommu
On Fri, 01 Feb 2019 17:09:57 +0100,
Christoph Hellwig wrote:
>
> On Fri, Feb 01, 2019 at 02:16:08PM +0100, Takashi Iwai wrote:
> > Actually there are a bunch of ISA sound drivers that still call
> > allocators with NULL device.
> >
> > The patch below should address it, although it's only compile-tested.
>
> Oh, I missed these "indirect" calls. This looks good to me:
>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
OK, merged this one to for-next branch now as well.
thanks,
Takashi
^ permalink raw reply [flat|nested] 41+ messages in thread