Skip to contentSkip to conversation

Correct Tegra20 FUSE driver DMA usage

PATCH In review Dmitry Osipenko 3 participants 6 messages Oct 19, 2017 – Nov 14, 2017 3 messages not in the archive Tegra architecture support

lore
Share & tools
lore

Dmitry Osipenko

author
#0 lore raw

v3 cover Correct Tegra20 FUSE driver DMA usage

Change log:

v3:
- Addressed v2 review comments: added 'config.device_fc = false' and utilize of_device_is_compatible() for dma-filter

v2:
- Dropped DT patch as turned out it was incorrect and made things work by luck.

- Now FUSE driver requests DMA channel from the APB DMA driver utilizing DMA channel filter.

- This patchset now depends on the APB DMA driver patch that allows DMA client to issue a non-flow controlled transfers. I haven't included that patch to this patchset since DMA usage is broken anyway right now. It will work once this patchset and APBDMA patch get applied.

Dmitry Osipenko (2):
soc/tegra: fuse: Fix reading registers using DMA on Tegra20 soc/tegra: fuse: Explicitly request DMA channel from APB DMA driver

 drivers/soc/tegra/fuse/fuse-tegra.c   |  1 +
 drivers/soc/tegra/fuse/fuse-tegra20.c | 13 +++++++++++--
 2 files changed, 12 insertions(+), 2 deletions(-)
Signature · 1 line
2.14.2
author
#2 lore raw

PATCH v3 1/2 soc/tegra: fuse: Fix reading registers using DMA on Tegra20

In reply to a message not in the archive

FUSE driver doesn't configure DMA channel properly, because of it DMA transfer is never issued and tegra20_fuse_read() always return 0x0.

Signed-off-by Dmitry Osipenko <[email protected]>
Acked-by Jon Hunter <[email protected]>
---
 drivers/soc/tegra/fuse/fuse-tegra.c   | 1 +
 drivers/soc/tegra/fuse/fuse-tegra20.c | 4 +++-
 2 files changed, 4 insertions(+), 1 deletion(-)
drivers/soc/tegra/fuse/fuse-tegra.c +1 -0
index b7c552e3133c..73a3a2c74021 100644
@@ -132,6 +132,7 @@ static int tegra_fuse_probe(struct platform_device *pdev)
 
 	/* take over the memory region from the early initialization */
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	fuse->phys = res->start;
 	fuse->base = devm_ioremap_resource(&pdev->dev, res);
 	if (IS_ERR(fuse->base))
 		return PTR_ERR(fuse->base);
drivers/soc/tegra/fuse/fuse-tegra20.c +3 -1
index 294413a969a0..27e9ac7d3165 100644
@@ -59,7 +59,7 @@ static u32 tegra20_fuse_read(struct tegra_fuse *fuse, unsigned int offset)
 
 	mutex_lock(&fuse->apbdma.lock);
 
-	fuse->apbdma.config.src_addr = fuse->apbdma.phys + FUSE_BEGIN + offset;
+	fuse->apbdma.config.src_addr = fuse->phys + FUSE_BEGIN + offset;
 
 	err = dmaengine_slave_config(fuse->apbdma.chan, &fuse->apbdma.config);
 	if (err)

@@ -119,6 +119,8 @@ static int tegra20_fuse_probe(struct tegra_fuse *fuse)
 	fuse->apbdma.config.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
 	fuse->apbdma.config.src_maxburst = 1;
 	fuse->apbdma.config.dst_maxburst = 1;
+	fuse->apbdma.config.direction = DMA_DEV_TO_MEM;
+	fuse->apbdma.config.device_fc = false;
 
 	init_completion(&fuse->apbdma.wait);
 	mutex_init(&fuse->apbdma.lock);
Signature · 1 line
2.14.2
author
#3 lore raw

PATCH v3 2/2 soc/tegra: fuse: Explicitly request DMA channel from APB DMA driver

In reply to a message not in the archive

Currently fuse driver requests DMA channel from an arbitrary DMA device, it is not a problem since there is only one DMA provider for Tegra20 yet, but it may become troublesome if another provider will appear.

Signed-off-by Dmitry Osipenko <[email protected]>
---
 drivers/soc/tegra/fuse/fuse-tegra20.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)
drivers/soc/tegra/fuse/fuse-tegra20.c +8 -1
index 27e9ac7d3165..49ff017f3ded 100644
@@ -96,6 +96,13 @@ static u32 tegra20_fuse_read(struct tegra_fuse *fuse, unsigned int offset)
 	return value;
 }
 
+static bool dma_filter(struct dma_chan *chan, void *filter_param)
+{
+	struct device_node *np = chan->device->dev->of_node;
+
+	return of_device_is_compatible(np, "nvidia,tegra20-apbdma");
+}
+
 static int tegra20_fuse_probe(struct tegra_fuse *fuse)
 {
 	dma_cap_mask_t mask;

@@ -103,7 +110,7 @@ static int tegra20_fuse_probe(struct tegra_fuse *fuse)
 	dma_cap_zero(mask);
 	dma_cap_set(DMA_SLAVE, mask);
 
-	fuse->apbdma.chan = dma_request_channel(mask, NULL, NULL);
+	fuse->apbdma.chan = __dma_request_channel(&mask, dma_filter, NULL);
 	if (!fuse->apbdma.chan)
 		return -EPROBE_DEFER;
Signature · 1 line
2.14.2
Acked-by
#5 lore raw

Re: [PATCH v3 2/2] soc/tegra: fuse: Explicitly request DMA channel from APB DMA driver

In reply to a message not in the archive
Quoted 28 lines · Dmitry Osipenko

Currently fuse driver requests DMA channel from an arbitrary DMA device, it is not a problem since there is only one DMA provider for Tegra20 yet, but it may become troublesome if another provider will appear.

Signed-off-by Dmitry Osipenko <[email protected]>
---
 drivers/soc/tegra/fuse/fuse-tegra20.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)
drivers/soc/tegra/fuse/fuse-tegra20.c +7 -0
index 27e9ac7d3165..49ff017f3ded 100644
@@ -96,6 +96,13 @@ static u32 tegra20_fuse_read(struct tegra_fuse *fuse, unsigned int offset)
 	return value;
 }
 
+static bool dma_filter(struct dma_chan *chan, void *filter_param)
+{
+	struct device_node *np = chan->device->dev->of_node;
+
+	return of_device_is_compatible(np, "nvidia,tegra20-apbdma");
+}
+
 static int tegra20_fuse_probe(struct tegra_fuse *fuse)
 {
 	dma_cap_mask_t mask;

drivers/soc/tegra/fuse/fuse-tegra20.c static int tegra20_fuse_probe(struct tegra_fuse *fuse) · line 116

Quoted 8 lines
drivers/soc/tegra/fuse/fuse-tegra20.c +1 -1
@@ -103,7 +110,7 @@ static int tegra20_fuse_probe(struct tegra_fuse *fuse)
 	dma_cap_zero(mask);
 	dma_cap_set(DMA_SLAVE, mask);
 
-	fuse->apbdma.chan = dma_request_channel(mask, NULL, NULL);
+	fuse->apbdma.chan = __dma_request_channel(&mask, dma_filter, NULL);
 	if (!fuse->apbdma.chan)
 		return -EPROBE_DEFER;

Thanks!

Acked-by Jon Hunter <[email protected]>

Thierry, these are ready for queuing.

Cheers
Jon

Signature · 1 line
nvpublic
author
#6 lore raw
In reply to a message not in the archive
Quoted 19 lines · Dmitry Osipenko

Change log:

v3:
- Addressed v2 review comments: added 'config.device_fc = false' and utilize of_device_is_compatible() for dma-filter

v2:
- Dropped DT patch as turned out it was incorrect and made things work by luck.

- Now FUSE driver requests DMA channel from the APB DMA driver utilizing DMA channel filter.

- This patchset now depends on the APB DMA driver patch that allows DMA client to issue a non-flow controlled transfers. I haven't included that patch to this patchset since DMA usage is broken anyway right now. It will work once this patchset and APBDMA patch get applied.

Quoted 8 lines

Dmitry Osipenko (2):
soc/tegra: fuse: Fix reading registers using DMA on Tegra20 soc/tegra: fuse: Explicitly request DMA channel from APB DMA driver

 drivers/soc/tegra/fuse/fuse-tegra.c   |  1 +
 drivers/soc/tegra/fuse/fuse-tegra20.c | 13 +++++++++++--
 2 files changed, 12 insertions(+), 2 deletions(-)

Thierry, why this patchset isn't in 'for 4.15' PR?

#8 lore raw
In reply to a message not in the archive
Quoted 24 lines · Dmitry Osipenko
Quoted 23 lines · Dmitry Osipenko

Change log:

v3:
- Addressed v2 review comments: added 'config.device_fc = false' and utilize of_device_is_compatible() for dma-filter

v2:
- Dropped DT patch as turned out it was incorrect and made things work by luck.

- Now FUSE driver requests DMA channel from the APB DMA driver utilizing DMA channel filter.

- This patchset now depends on the APB DMA driver patch that allows DMA client to issue a non-flow controlled transfers. I haven't included that patch to this patchset since DMA usage is broken anyway right now. It will work once this patchset and APBDMA patch get applied.

Dmitry Osipenko (2):
soc/tegra: fuse: Fix reading registers using DMA on Tegra20 soc/tegra: fuse: Explicitly request DMA channel from APB DMA driver

Quoted 6 lines
Quoted 4 lines
 drivers/soc/tegra/fuse/fuse-tegra.c   |  1 +
 drivers/soc/tegra/fuse/fuse-tegra20.c | 13 +++++++++++--
 2 files changed, 12 insertions(+), 2 deletions(-)

Thierry, why this patchset isn't in 'for 4.15' PR?

Looking at the date, this was sent on the same day that I sent out the pull requests. For ARM-SoC (and many other trees) the cut-off point is -rc6 of the prior release cycle. This means that any work you'd like to see go into a release needs to be on the list a couple of days before that. I usually do pull requests on Thursday or Friday before an -rc6 release and by that time I want things to have cooked in -next for a day or two at least.

Thierry