Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello.

On 02-02-2013 23:55, Matt Porter wrote:

Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically AM33xx) as well.

I think this should rather go to drivers/dma/?

No, this is the private EDMA API. It's the analogous thing to
the private OMAP dma API that is in plat-omap/dma.c. The actual
dmaengine driver is in drivers/dma/edma.c as a wrapper around
this...same way OMAP DMA engine conversion is being done.

     Keeps me wondering why we couldn't have the same with CPPI 4.1 when I proposed
that, instead of waiting indefinitely for TI to convert it to drivers/dma/
directly. We could have working MUSB DMA on OMAP-L1x/Sitara all this time... Sigh.

That is a shame. Yeah, I've pointed out that I was doing this exactly
the same way as was acceptable for the OMAP DMA conversion since it was
in RFC. The reasons are sound since in both cases, we have many drivers
to convert that need to continue using the private DMA APIs.

      In case of CPPI 4.1, we'd only have to convert MUSB DMA driver. Other
in-tree CPPI 4.1 having SoCs don't use it for anything but MUSB -- it even is
sub-block of their MUSB device, AFAIK (I maybe wrong about Sitaras -- I don't
know them well).

Well, it's pretty clear to me now that there's good reason for it not
landing in arch/arm/ so the obvious path is to do the dmaengine
conversion and put it in drivers/dma/ if it's really a generic dma engine.
I'm not sure why you express concern over the dma engine api not fitting
with CPPI 4.1?

     It's not a DMA controller only, it's 3 distinct devices, with the DMA
controller being one among them and using another one, the queue manager, as
some sort of proxy. The third device doesn't exist on OMAP-L1x SoCs -- it's
the buffer manager.

Interesting, and you don't see a way to have this split between
dmaengine and the musb driver?

This can't be split into the MUSB DMA driver, as the neither of CPPI 4.1 devices are really MUSB specific. The support should be generic.

This all assumes there's even a match as
RMK did raise concerns elsewhere in this thread.

   Didn't quite get this sentence.

If it doesn't work, work with Vinod to fix the api. It's
expected, I'm working on dmaengine API changes right now to deal with a
limitation of EDMA that needs to be abstracted.

     Sorry, now it's TI's task. I no longer have time to work on this (my
internal project to push OMAP-L1x support upstream has expired at Sep 2010)

If not somewhat earlier... anyway, I wasn't able to spent much time on this project in 2010.

and my future in MV is very uncertain at this moment. Most probably I'll leave
it (or be forced to leave).

Too bad, it's certainly "somebody's task". The people employed by TI
have names too. ;) I suspect it falls to Felipe or Kishon these days,
but I try to avoid USB as it's generally a source of pain.

I'm probably masochistic then since I'm still sending MUSB patches, eben though I wasn't working on it at MV until I switched to Kontron boards 2 weeks ago. Now my task is fixing USB bugs on real Sitara with dual MUSB. :-)

As pointed out, edma.c is already here in arch/arm/, so moving it doesn't
add something new. It does let us regression test all platforms that use it
(both Davinci and AM33xx) as I go through the conversion process.

     Could have been the same with CPPI 4.1 in theory if it was added to
mach-davinci/ back in 2009... we'd then only have to move it. EDMA code is

I don't know why Kevin didn't merge it then. I remembere he didn't like that it was not a proper platform driver and was tied with the platform code thru some variables, and I refused to change that...

much older of course, so it's probably more justified.

Absolutely, timing is everything. I can assure you I've flamed enough
people "internally" about leaving this EDMA dmaengine conversion for so
long. As you might have guessed, AM33xx is a bit of a driver for it, but
all of this would have been quite a bit simpler had somebody taken a
little effort and moved edma to dmaengine years ago when slave dma
support was added to dmaengine. ;)

Hm, it seems to have happened back in 2008 when I was working on CPPI 4.1 code. Too bad I only knew that drivers/dma/ are for accelerating RAIDs back then (if actually noot later than that). TI seems to put more efforts into its Arago project than in supoporting the cutting edge (or not) CPUs in mainline -- at lest things seem go there first. Many Arago patches never reached mainline (not that they can be applied without cleanup though).

-Matt

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux