Sergei Shtylyov <[email protected]> writes: > Hello, I wrote: > >>>>>>>>>>> Some of the comments about my earlier EDMA patches touched >>>>>>>>>>> on issues >>>>>>>>>>> in that programming interface, like: > >>>>>>>>>>> - The single call to allocate DMA resources is overly complex. > >>>>>>>>>>> - Its programming model doesn't match the hardware well: talking >>>>>>>>>>> about master vs. slave, not channels and parameter RAM; confusing >>>>>>>>>>> those two resource types (especially when allocating); etc. > >>>>>>>>>>> - Since the calls used a "davinci_" prefix, they wouldn't be very >>>>>>>>>>> appropriate for the DMA in the OMAP-L137 chip. >> >> >>>>>>>>>> We were going to move the generic part of >>>>>>>>>> arch/arm/mach-davinci/dma.c (alomg with other common code b/w so >>>>>>>>>> called OMAP-L1x and DaVinci) to arch/arm/plat-davinci/ but >>>>>>>>>> the rename >>>>>>>>>> seems reasonable anyway. >> >> >>>>>>>>> I keep hearing things like this, but have not yet seen any >>>>>>>>> patches, or >>>>>>>>> technical arguments for doing so. >> >> >>>>>>>> The technical argument is simple: sharing the code for two similar >>>>>>>> platforms, the EDMA code in particular. > >>>>>>> The code already is shared. > >>>>>> How? You're not supposed to looks for the shared code in other >>>>>> mach-*/ dirs, are you? > >>>>> I'm talking about DaVinci git tree here, not TI/MV trees. There is >>>>> no plat-davinci, only a mach-davinci. > >>>>> The current DMA code is shared across the various devices currently >>>>> supported in DaVinci git. > >>>>> The point I'm trying to make is that I still do not agree with the >>>>> need to create a plat-davinci for "common" code. The reasons I've >>>>> heard so far have not been convincing. > >>>> So, you want e.g. EDMA code duplicated, right? > >>> Um, no. You are the one who seems to be implying a new mach-* >>> directory for a new platform which would require duplication. > >>> The way I currently see things is a single mach-davinci with support >>> for dm644x, dm355, dm646x, omapl1x7, etc. > >> MV too have clinged to the idea of "parasitising" on the DaVinci >> code till the last possibility but then finally ditched it. > >>> Until technical reasons for the creation of a new mach-* directory are >>> proposed and discussed on the list, that's the way I plan to continue >>> things. > >> If completely different interrupt controller doesn't sound as >> sufficient technical reason, I think I won't be wasting any more >> time on this argument. Hopefully others will be able to provide >> better arguments. I've been tired enough by the internal discussion >> already.
A new interrupt controller can simply be added with a new 'cp_intc.c' in current mach-davinci. IIRC, this is how it was done in the initial port. > Just one last argument, to be as technical as possible: > entry-macro.S will need either #ifdef'ery (thus defying your presumed > idea of having the single binary to boot on all DaVinci like > platfroms) or some kind of runtime check (at one point we did > implement that) in order to function on both platfroms. Are you sure > we need all that? IIRC, Steve Chen found a simple way to do this by creating a virtual mapping that maps both INTC areas to the same range, and having a check in entry-macro.S. This idea can be extended such that if the kernel is not built for multiple devices, the optimized, chip specific version can be used. Kevin _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
