On Fri, Feb 01, 2013 at 01:59:59PM -0500, Matt Porter wrote: > On Fri, Feb 01, 2013 at 07:52:46PM +0000, Sergei Shtylyov wrote: > > Hello. > > > > On 02/01/2013 09:49 PM, 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. It's very simple. The OMAP DMA stuff in plat-omap/dma.c has existed for a long time, well before things like the DMA engine API came into being. Same with a lot of the DMA code in arch/arm. It is therefore in the privileged position of having "grandfather" rights when it comes to existing in mainline. However, today what we're finding is that these private per-platform APIs are sub-optimal; they prevent the peripheral drivers in the drivers/ subtree from being re-used on other SoCs. So, even through they pre-exist the DMA engine support, they're being gradually converted to the API. Moreover, we have _far_ too much code in arch/arm. It's something that has been attracted complaints from Linus. It's something that's got us close to having updates to arch/arm refused during merge windows. It's got us close to having parts of arch/arm deleted from the mainline kernel. The long term plan is _still_ to remove arch/arm/*omap*/dma.c and move the whole thing to drivers/dma. That can only happen when everything is converted (or the drivers which aren't converted have been retired and deleted) - and provided that TI decide to continue funding that work. That's still uncertain since the whole TI OMAP thing imploded two months ago. Now, CPPI is brand new code to arch/arm - always has been. It post-dates the DMA engine API. And it's been said many times about moving it to drivers/dma. The problem is Sergei doesn't want to do it - he's anti the DMA engine API for whatever reasons he can dream up. He professes no knowledge of my dislike for having it in arch/arm, yet there's emails from years back showing that he knew about it. TI knows about it; Ajay about it. Yet... well... history speaks volumes about this. Now, there may be a new problem with CPPI. That being we're now requiring DT support. _Had_ this been done prior to the push for DT, then it would not have been a concern, because then the problem becomes one for DT. But now that OMAP is being converted to DT, and DT is The Way To Go now, that's an additional problem that needs to be grappled with - or it may make things easier. However, as I've said now many times: CPPI is _not_ going in arch/arm. Period. That makes it not my problem. Period. I really have nothing further to say on CPPI; everything that can be said has already been said. If there's still pressure to have it in arch/arm, I will _NOT_ respond to it, because there's nothing to be said about it which hasn't been said before. The only reason it's still being pressed for is a total reluctance to do anything about it being in arch/arm. -- 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
