[PATCH RFC] media: platform: fcp: Set appropriate DMA parameters

[PATCH RFC] media: platform: fcp: Set appropriate DMA parameters

[Kieran Bingham]

Enabling CONFIG_DMA_API_DEBUG=y and CONFIG_DMA_API_DEBUG_SG=y will
enable extra validation on DMA operations ensuring that the size
restraints are met.

When using the FCP in conjunction with the VSP1/DU, and display frames,
the size of the DMA operations is larger than the default maximum
segment size reported by the DMA core (64K). With the DMA debug enabled,
this produces a warning such as the following:

"DMA-API: rcar-fcp fea27000.fcp: mapping sg segment longer than device"

We have no specific limitation on the segment size which isn't already
handled by the VSP1/DU which actually handles the DMA allcoations and
buffer management, so define a maximum segment size of up to 4GB (a 32
bit mask).

Fixes: 7b49235e83b2 ("[media] v4l: Add Renesas R-Car FCP driver")

Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>

---

I see no reference to any specific limitation on the FCP in regards to
DMA operation size, but there are limitations on the supported image
sizes at 8190*8190 pixels. (smaller for FCPC at 3190) As that could be at
various BPP which is unkown to the FCP driver, and because any maximum
limitation should already be provided elsewhere, I don't think we need
to arbitrarly define a maximum segment size here, so defaulting to a '32
bit maximum' to prevent uneccessary warnings from being printed.

Alternatively, we could assume a 4BPP, and define maximum segment sizes
based upon the maximum capabilities of each FCP instance, but I'm not
sure if that will be

Interestingly though, the FCP should have an alignment of 256 byte
boundarys on buffers, but I don't yet see a means to validate that
through CONFIG_DMA_API_DEBUG/CONFIG_DMA_API_DEBUG_SG.
---
 drivers/media/platform/rcar-fcp.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/media/platform/rcar-fcp.c b/drivers/media/platform/rcar-fcp.c
index 43c78620c9d8..5c6b00737fe7 100644
--- a/drivers/media/platform/rcar-fcp.c
+++ b/drivers/media/platform/rcar-fcp.c
@@ -8,6 +8,7 @@
  */
 
 #include <linux/device.h>
+#include <linux/dma-mapping.h>
 #include <linux/list.h>
 #include <linux/module.h>
 #include <linux/mod_devicetable.h>
@@ -21,6 +22,7 @@
 struct rcar_fcp_device {
 	struct list_head list;
 	struct device *dev;
+	struct device_dma_parameters dma_parms;
 };
 
 static LIST_HEAD(fcp_devices);
@@ -136,6 +138,9 @@ static int rcar_fcp_probe(struct platform_device *pdev)
 
 	fcp->dev = &pdev->dev;
 
+	fcp->dev->dma_parms = &fcp->dma_parms;
+	dma_set_max_seg_size(fcp->dev, DMA_BIT_MASK(32));
+
 	pm_runtime_enable(&pdev->dev);
 
 	mutex_lock(&fcp_lock);
-- 
2.20.1

Re: [PATCH RFC] media: platform: fcp: Set appropriate DMA parameters

[Geert Uytterhoeven]

Hi Kieran,

On Wed, Mar 18, 2020 at 6:23 PM Kieran Bingham
<kieran.bingham+renesas@ideasonboard.com> wrote:
> Enabling CONFIG_DMA_API_DEBUG=y and CONFIG_DMA_API_DEBUG_SG=y will
> enable extra validation on DMA operations ensuring that the size
> restraints are met.
>
> When using the FCP in conjunction with the VSP1/DU, and display frames,
> the size of the DMA operations is larger than the default maximum
> segment size reported by the DMA core (64K). With the DMA debug enabled,
> this produces a warning such as the following:
>
> "DMA-API: rcar-fcp fea27000.fcp: mapping sg segment longer than device"

... claims to support [len=3145728] [max=65536]

> We have no specific limitation on the segment size which isn't already
> handled by the VSP1/DU which actually handles the DMA allcoations and
> buffer management, so define a maximum segment size of up to 4GB (a 32
> bit mask).

Reported-by: Geert Uytterhoeven <geert+renesas@glider.be>

> Fixes: 7b49235e83b2 ("[media] v4l: Add Renesas R-Car FCP driver")
>
> Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

The warning is gone, so:
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>

Haven't tested the actual display, though.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds