* Using PTDMA driver for generic DMA
@ 2024-02-02 16:57 Tadeusz Struk
2024-02-07 13:26 ` Raju Rangoju
0 siblings, 1 reply; 11+ messages in thread
From: Tadeusz Struk @ 2024-02-02 16:57 UTC (permalink / raw)
To: Sanjay R Mehta, Gary R Hook, Tom Lendacky; +Cc: dmaengine, Eric Pilmore, tstruk
Hello,
I'm trying to use the AMD PTDMA engine for generic data transfers,
but I can't get it to work.
It fails for me with "ptdma 0000:52:00.2: PTDMA error: (null) (0x27)"
which, I'm guessing, translates to "ERR 39: ODMA0_AXI_DECERR"
After some research I've found a note in drivers/dma/ptdma/Kconfig,
which says that "...this DMA controller is intended to be used with
AMD Non-Transparent Bridge devices and not for general purpose
peripheral DMA."
My question is, what is the "ERR 39: ODMA0_AXI_DECERR", and is it even
possible to use the PTDMA engine to talk to anything else other than
AMD NTB?
Thanks,
Tadeusz
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Using PTDMA driver for generic DMA
2024-02-02 16:57 Using PTDMA driver for generic DMA Tadeusz Struk
@ 2024-02-07 13:26 ` Raju Rangoju
2024-02-07 16:44 ` Eric Pilmore
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Raju Rangoju @ 2024-02-07 13:26 UTC (permalink / raw)
To: Tadeusz Struk, Sanjay R Mehta, Gary R Hook, Tom Lendacky
Cc: dmaengine, Eric Pilmore, Basavaraj Natikar
Hello Tadeusz,
Sorry for the delay in response.
The "ERR 39: ODMA0_AXI_DECERR" is a Decode Error relating to destination.
Please note that, the PTDMA DMA controller is intended to be used with
AMD Non-Transparent Bridge devices and not for general purpose
peripheral DMA use cases. PTDMA engine can not talk to anything other
than NTB device.
Thanks,
Raju
On 2/2/2024 10:27 PM, Tadeusz Struk wrote:
> Hello,
> I'm trying to use the AMD PTDMA engine for generic data transfers,
> but I can't get it to work.
> It fails for me with "ptdma 0000:52:00.2: PTDMA error: (null) (0x27)"
> which, I'm guessing, translates to "ERR 39: ODMA0_AXI_DECERR"
> After some research I've found a note in drivers/dma/ptdma/Kconfig,
> which says that "...this DMA controller is intended to be used with
> AMD Non-Transparent Bridge devices and not for general purpose
> peripheral DMA."
> My question is, what is the "ERR 39: ODMA0_AXI_DECERR", and is it even
> possible to use the PTDMA engine to talk to anything else other than
> AMD NTB?
>
> Thanks,
> Tadeusz
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Using PTDMA driver for generic DMA
2024-02-07 13:26 ` Raju Rangoju
@ 2024-02-07 16:44 ` Eric Pilmore
2024-02-09 8:16 ` Tadeusz Struk
2024-02-19 20:10 ` [PATCH] dmaengine: ptdma: use consistent DMA masks Tadeusz Struk
2 siblings, 0 replies; 11+ messages in thread
From: Eric Pilmore @ 2024-02-07 16:44 UTC (permalink / raw)
To: Raju Rangoju
Cc: Tadeusz Struk, Sanjay R Mehta, Gary R Hook, Tom Lendacky,
dmaengine, Basavaraj Natikar
On Wed, Feb 7, 2024 at 5:26 AM Raju Rangoju <Raju.Rangoju@amd.com> wrote:
>
> Hello Tadeusz,
>
> Sorry for the delay in response.
>
> The "ERR 39: ODMA0_AXI_DECERR" is a Decode Error relating to destination.
>
> Please note that, the PTDMA DMA controller is intended to be used with
> AMD Non-Transparent Bridge devices and not for general purpose
> peripheral DMA use cases. PTDMA engine can not talk to anything other
> than NTB device.
>
> Thanks,
> Raju
Hi Raju,
Are you able to share why the PTDMA has that limitation? How does it
even know whether it's talking to an (AMD) NTB device? Is there some
special handshaking or flow control happening that only works in
conjunction with the AMD NTB?
I understand if that may be a company confidential thing and you can't
disclose, but it just seems odd that a standalone DMA engine would
only function if its destination address represented only one specific
type of device.
Thanks,
Eric
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Using PTDMA driver for generic DMA
2024-02-07 13:26 ` Raju Rangoju
2024-02-07 16:44 ` Eric Pilmore
@ 2024-02-09 8:16 ` Tadeusz Struk
2024-02-19 20:10 ` [PATCH] dmaengine: ptdma: use consistent DMA masks Tadeusz Struk
2 siblings, 0 replies; 11+ messages in thread
From: Tadeusz Struk @ 2024-02-09 8:16 UTC (permalink / raw)
To: Raju Rangoju, Sanjay R Mehta, Gary R Hook, Tom Lendacky
Cc: dmaengine, Eric Pilmore, Basavaraj Natikar
Hi Raju,
On 2/7/24 14:26, Raju Rangoju wrote:
> Hello Tadeusz,
>
> Sorry for the delay in response.
>
> The "ERR 39: ODMA0_AXI_DECERR" is a Decode Error relating to destination.
Could you please send a patch that adds short comments explaining these
error codes similar to this one?
Thanks and regards,
Tadeusz
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH] dmaengine: ptdma: use consistent DMA masks
2024-02-07 13:26 ` Raju Rangoju
2024-02-07 16:44 ` Eric Pilmore
2024-02-09 8:16 ` Tadeusz Struk
@ 2024-02-19 20:10 ` Tadeusz Struk
2024-02-20 7:12 ` Basavaraj Natikar
` (2 more replies)
2 siblings, 3 replies; 11+ messages in thread
From: Tadeusz Struk @ 2024-02-19 20:10 UTC (permalink / raw)
To: Vinod Koul
Cc: Raju Rangoju, Basavaraj Natikar, Tom Lendacky, Sanjay R Mehta,
Eric Pilmore, dmaengine, Tadeusz Struk, stable
The PTDMA driver sets DMA masks in two different places for the same
device inconsistently. First call is in pt_pci_probe(), where it uses
48bit mask. The second call is in pt_dmaengine_register(), where it
uses a 64bit mask. Using 64bit dma mask causes IO_PAGE_FAULT errors
on DMA transfers between main memory and other devices.
Without the extra call it works fine. Additionally the second call
doesn't check the return value so it can silently fail.
Remove the superfluous dma_set_mask() call and only use 48bit mask.
Cc: stable@vger.kernel.org
Fixes: b0b4a6b10577 ("dmaengine: ptdma: register PTDMA controller as a DMA resource")
Signed-off-by: Tadeusz Struk <tstruk@gigaio.com>
---
drivers/dma/ptdma/ptdma-dmaengine.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/dma/ptdma/ptdma-dmaengine.c b/drivers/dma/ptdma/ptdma-dmaengine.c
index 1aa65e5de0f3..f79240734807 100644
--- a/drivers/dma/ptdma/ptdma-dmaengine.c
+++ b/drivers/dma/ptdma/ptdma-dmaengine.c
@@ -385,8 +385,6 @@ int pt_dmaengine_register(struct pt_device *pt)
chan->vc.desc_free = pt_do_cleanup;
vchan_init(&chan->vc, dma_dev);
- dma_set_mask_and_coherent(pt->dev, DMA_BIT_MASK(64));
-
ret = dma_async_device_register(dma_dev);
if (ret)
goto err_reg;
--
2.43.2
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH] dmaengine: ptdma: use consistent DMA masks
2024-02-19 20:10 ` [PATCH] dmaengine: ptdma: use consistent DMA masks Tadeusz Struk
@ 2024-02-20 7:12 ` Basavaraj Natikar
2024-02-22 13:56 ` Vinod Koul
2024-02-23 12:08 ` [PATCH] " Vinod Koul
2 siblings, 0 replies; 11+ messages in thread
From: Basavaraj Natikar @ 2024-02-20 7:12 UTC (permalink / raw)
To: Tadeusz Struk, Vinod Koul
Cc: Raju Rangoju, Basavaraj Natikar, Tom Lendacky, Sanjay R Mehta,
Eric Pilmore, dmaengine, Tadeusz Struk, stable
On 2/20/2024 1:40 AM, Tadeusz Struk wrote:
> The PTDMA driver sets DMA masks in two different places for the same
> device inconsistently. First call is in pt_pci_probe(), where it uses
> 48bit mask. The second call is in pt_dmaengine_register(), where it
> uses a 64bit mask. Using 64bit dma mask causes IO_PAGE_FAULT errors
> on DMA transfers between main memory and other devices.
> Without the extra call it works fine. Additionally the second call
> doesn't check the return value so it can silently fail.
> Remove the superfluous dma_set_mask() call and only use 48bit mask.
>
> Cc: stable@vger.kernel.org
> Fixes: b0b4a6b10577 ("dmaengine: ptdma: register PTDMA controller as a DMA resource")
>
> Signed-off-by: Tadeusz Struk <tstruk@gigaio.com>
> ---
> drivers/dma/ptdma/ptdma-dmaengine.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/dma/ptdma/ptdma-dmaengine.c b/drivers/dma/ptdma/ptdma-dmaengine.c
> index 1aa65e5de0f3..f79240734807 100644
> --- a/drivers/dma/ptdma/ptdma-dmaengine.c
> +++ b/drivers/dma/ptdma/ptdma-dmaengine.c
> @@ -385,8 +385,6 @@ int pt_dmaengine_register(struct pt_device *pt)
> chan->vc.desc_free = pt_do_cleanup;
> vchan_init(&chan->vc, dma_dev);
>
> - dma_set_mask_and_coherent(pt->dev, DMA_BIT_MASK(64));
> -
Looks good to me
Reviewed-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
> ret = dma_async_device_register(dma_dev);
> if (ret)
> goto err_reg;
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] dmaengine: ptdma: use consistent DMA masks
2024-02-19 20:10 ` [PATCH] dmaengine: ptdma: use consistent DMA masks Tadeusz Struk
2024-02-20 7:12 ` Basavaraj Natikar
@ 2024-02-22 13:56 ` Vinod Koul
2024-02-22 16:24 ` Tadeusz Struk
2024-02-22 16:30 ` [PATCH RESEND] " Tadeusz Struk
2024-02-23 12:08 ` [PATCH] " Vinod Koul
2 siblings, 2 replies; 11+ messages in thread
From: Vinod Koul @ 2024-02-22 13:56 UTC (permalink / raw)
To: Tadeusz Struk
Cc: Raju Rangoju, Basavaraj Natikar, Tom Lendacky, Sanjay R Mehta,
Eric Pilmore, dmaengine, Tadeusz Struk, stable
On 19-02-24, 21:10, Tadeusz Struk wrote:
> The PTDMA driver sets DMA masks in two different places for the same
> device inconsistently. First call is in pt_pci_probe(), where it uses
> 48bit mask. The second call is in pt_dmaengine_register(), where it
> uses a 64bit mask. Using 64bit dma mask causes IO_PAGE_FAULT errors
> on DMA transfers between main memory and other devices.
> Without the extra call it works fine. Additionally the second call
> doesn't check the return value so it can silently fail.
> Remove the superfluous dma_set_mask() call and only use 48bit mask.
>
> Cc: stable@vger.kernel.org
> Fixes: b0b4a6b10577 ("dmaengine: ptdma: register PTDMA controller as a DMA resource")
>
No empty line here please
> Signed-off-by: Tadeusz Struk <tstruk@gigaio.com>
I cant pick this, it was sent by email which this patch was not
signed-off by, please either resend from same id as sob or sign with
both
> ---
> drivers/dma/ptdma/ptdma-dmaengine.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/dma/ptdma/ptdma-dmaengine.c b/drivers/dma/ptdma/ptdma-dmaengine.c
> index 1aa65e5de0f3..f79240734807 100644
> --- a/drivers/dma/ptdma/ptdma-dmaengine.c
> +++ b/drivers/dma/ptdma/ptdma-dmaengine.c
> @@ -385,8 +385,6 @@ int pt_dmaengine_register(struct pt_device *pt)
> chan->vc.desc_free = pt_do_cleanup;
> vchan_init(&chan->vc, dma_dev);
>
> - dma_set_mask_and_coherent(pt->dev, DMA_BIT_MASK(64));
> -
> ret = dma_async_device_register(dma_dev);
> if (ret)
> goto err_reg;
> --
> 2.43.2
--
~Vinod
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] dmaengine: ptdma: use consistent DMA masks
2024-02-22 13:56 ` Vinod Koul
@ 2024-02-22 16:24 ` Tadeusz Struk
2024-02-22 16:30 ` [PATCH RESEND] " Tadeusz Struk
1 sibling, 0 replies; 11+ messages in thread
From: Tadeusz Struk @ 2024-02-22 16:24 UTC (permalink / raw)
To: Vinod Koul, Tadeusz Struk
Cc: Raju Rangoju, Basavaraj Natikar, Tom Lendacky, Sanjay R Mehta,
Eric Pilmore, dmaengine, stable
On 2/22/24 14:56, Vinod Koul wrote:
>> Signed-off-by: Tadeusz Struk<tstruk@gigaio.com>
> I cant pick this, it was sent by email which this patch was not
> signed-off by, please either resend from same id as sob or sign with
> both
I will resend with a proper "From" line now.
Thanks,
Tadeusz
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH RESEND] dmaengine: ptdma: use consistent DMA masks
2024-02-22 13:56 ` Vinod Koul
2024-02-22 16:24 ` Tadeusz Struk
@ 2024-02-22 16:30 ` Tadeusz Struk
2024-02-23 12:08 ` Vinod Koul
1 sibling, 1 reply; 11+ messages in thread
From: Tadeusz Struk @ 2024-02-22 16:30 UTC (permalink / raw)
To: Vinod Koul
Cc: Basavaraj Natikar, Tom Lendacky, Eric Pilmore, dmaengine,
Tadeusz Struk, stable
From: Tadeusz Struk <tstruk@gigaio.com>
The PTDMA driver sets DMA masks in two different places for the same
device inconsistently. First call is in pt_pci_probe(), where it uses
48bit mask. The second call is in pt_dmaengine_register(), where it
uses a 64bit mask. Using 64bit dma mask causes IO_PAGE_FAULT errors
on DMA transfers between main memory and other devices.
Without the extra call it works fine. Additionally the second call
doesn't check the return value so it can silently fail.
Remove the superfluous dma_set_mask() call and only use 48bit mask.
Cc: stable@vger.kernel.org
Fixes: b0b4a6b10577 ("dmaengine: ptdma: register PTDMA controller as a DMA resource")
Reviewed-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Signed-off-by: Tadeusz Struk <tstruk@gigaio.com>
---
drivers/dma/ptdma/ptdma-dmaengine.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/dma/ptdma/ptdma-dmaengine.c b/drivers/dma/ptdma/ptdma-dmaengine.c
index 1aa65e5de0f3..f79240734807 100644
--- a/drivers/dma/ptdma/ptdma-dmaengine.c
+++ b/drivers/dma/ptdma/ptdma-dmaengine.c
@@ -385,8 +385,6 @@ int pt_dmaengine_register(struct pt_device *pt)
chan->vc.desc_free = pt_do_cleanup;
vchan_init(&chan->vc, dma_dev);
- dma_set_mask_and_coherent(pt->dev, DMA_BIT_MASK(64));
-
ret = dma_async_device_register(dma_dev);
if (ret)
goto err_reg;
--
2.43.2
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH] dmaengine: ptdma: use consistent DMA masks
2024-02-19 20:10 ` [PATCH] dmaengine: ptdma: use consistent DMA masks Tadeusz Struk
2024-02-20 7:12 ` Basavaraj Natikar
2024-02-22 13:56 ` Vinod Koul
@ 2024-02-23 12:08 ` Vinod Koul
2 siblings, 0 replies; 11+ messages in thread
From: Vinod Koul @ 2024-02-23 12:08 UTC (permalink / raw)
To: Tadeusz Struk
Cc: Raju Rangoju, Basavaraj Natikar, Tom Lendacky, Sanjay R Mehta,
Eric Pilmore, dmaengine, Tadeusz Struk, stable
On Mon, 19 Feb 2024 21:10:39 +0100, Tadeusz Struk wrote:
> The PTDMA driver sets DMA masks in two different places for the same
> device inconsistently. First call is in pt_pci_probe(), where it uses
> 48bit mask. The second call is in pt_dmaengine_register(), where it
> uses a 64bit mask. Using 64bit dma mask causes IO_PAGE_FAULT errors
> on DMA transfers between main memory and other devices.
> Without the extra call it works fine. Additionally the second call
> doesn't check the return value so it can silently fail.
> Remove the superfluous dma_set_mask() call and only use 48bit mask.
>
> [...]
Applied, thanks!
[1/1] dmaengine: ptdma: use consistent DMA masks
commit: df2515a17914ecfc2a0594509deaf7fcb8d191ac
Best regards,
--
~Vinod
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH RESEND] dmaengine: ptdma: use consistent DMA masks
2024-02-22 16:30 ` [PATCH RESEND] " Tadeusz Struk
@ 2024-02-23 12:08 ` Vinod Koul
0 siblings, 0 replies; 11+ messages in thread
From: Vinod Koul @ 2024-02-23 12:08 UTC (permalink / raw)
To: Tadeusz Struk
Cc: Basavaraj Natikar, Tom Lendacky, Eric Pilmore, dmaengine,
Tadeusz Struk, stable
On Thu, 22 Feb 2024 17:30:53 +0100, Tadeusz Struk wrote:
> The PTDMA driver sets DMA masks in two different places for the same
> device inconsistently. First call is in pt_pci_probe(), where it uses
> 48bit mask. The second call is in pt_dmaengine_register(), where it
> uses a 64bit mask. Using 64bit dma mask causes IO_PAGE_FAULT errors
> on DMA transfers between main memory and other devices.
> Without the extra call it works fine. Additionally the second call
> doesn't check the return value so it can silently fail.
> Remove the superfluous dma_set_mask() call and only use 48bit mask.
>
> [...]
Applied, thanks!
[1/1] dmaengine: ptdma: use consistent DMA masks
commit: df2515a17914ecfc2a0594509deaf7fcb8d191ac
Best regards,
--
~Vinod
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2024-02-23 12:08 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-02-02 16:57 Using PTDMA driver for generic DMA Tadeusz Struk
2024-02-07 13:26 ` Raju Rangoju
2024-02-07 16:44 ` Eric Pilmore
2024-02-09 8:16 ` Tadeusz Struk
2024-02-19 20:10 ` [PATCH] dmaengine: ptdma: use consistent DMA masks Tadeusz Struk
2024-02-20 7:12 ` Basavaraj Natikar
2024-02-22 13:56 ` Vinod Koul
2024-02-22 16:24 ` Tadeusz Struk
2024-02-22 16:30 ` [PATCH RESEND] " Tadeusz Struk
2024-02-23 12:08 ` Vinod Koul
2024-02-23 12:08 ` [PATCH] " Vinod Koul
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).