Thread (18 messages) 18 messages, 3 authors, 2018-01-24

Re: [PATCH 4/8] mfd: stm32-timers: add support for dmas

From: Fabrice Gasnier <hidden>
Date: 2018-01-24 08:41:13
Also in: linux-arm-kernel, linux-pwm, lkml

On 01/23/2018 05:41 PM, Lee Jones wrote:
On Tue, 23 Jan 2018, Fabrice Gasnier wrote:
quoted
On 01/23/2018 04:30 PM, Lee Jones wrote:
quoted
On Tue, 23 Jan 2018, Fabrice Gasnier wrote:
quoted
On 01/23/2018 02:32 PM, Lee Jones wrote:
quoted
On Tue, 16 Jan 2018, Fabrice Gasnier wrote:
quoted
STM32 Timers can support up to 7 dma requests:
4 channels, update, compare and trigger.
Optionally request part, or all dmas from stm32-timers MFD core.
Also, keep reference of device's bus address to allow child drivers to
transfer data from/to device by using dma.

Signed-off-by: Fabrice Gasnier <redacted>
---
 drivers/mfd/stm32-timers.c       | 37 ++++++++++++++++++++++++++++++++++++-
 include/linux/mfd/stm32-timers.h | 14 ++++++++++++++
 2 files changed, 50 insertions(+), 1 deletion(-)
diff --git a/drivers/mfd/stm32-timers.c b/drivers/mfd/stm32-timers.c
 static int stm32_timers_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
@@ -44,6 +61,7 @@ static int stm32_timers_probe(struct platform_device *pdev)
 	mmio = devm_ioremap_resource(dev, res);
 	if (IS_ERR(mmio))
 		return PTR_ERR(mmio);
+	ddata->phys_base = res->start;
What do you use this for?
This is used in in child driver (pwm) for capture data transfer by dma.
Might be worth being clear about that.

Perhaps pass in 'dma_base' (phys_base + offset) instead?
I guess you've had a look at [PATCH 5/8] pwm: stm32: add capture
support. Are you talking about passing phys_base + TIM_DMAR ?
I have and I am.
quoted
If this is the case, I'd prefer to keep phys base only if you don't
mind, and handle TIM_DMAR offset in pwm driver. This way, all dma slave
config is kept locally at one place.
Or do you mean something else ?

Maybe I can add a comment here about this ?
Something like:
/* phys_base to be used by child driver, e.g. DMA burst mode */
I haven't seen the memory map for this device, so it's not easy for me
to comment, but passing in the physical address of the parent MFD into
a child device doesn't quite sit right with me.

At what level does TIM_DMAR sit?  Is it a child (PWM) specific
property, or is it described at parent (Timer) level?
Hi Lee,

This isn't child (PWM) specific. TIM_DMAR is described at timer level as
well as all timers DMA requests lines. Current patchset make it useful
for PWM capture. Basically, I think this can be seen as interrupts, as
each (0..7) dma request has an enable bit (in DIER: interrupt enable
register). This is similar as interrupts at timer level.

So, I understand your point regarding passing physical address of the
parent MFD... Speaking of interrupts, I'd probably have looked at
irq_chip. Regarding dma, i'm not sure what is preferred way ?

Another way maybe to export a routine (export symbol) from MFD core, to
handle dma transfer from there?
By looking into drivers/mfd, I found similar approach, e.g.
rtsx_pci_dma_transfer(). Do you think this is better approach ?

Please let me know your opinion.

Best Regards,
Fabrice
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help