Steve Chen <[email protected]> writes: > Kevin, > > > On Mon, 2009-01-19 at 11:12 -0800, Kevin Hilman wrote: >> Sergei Shtylyov <[email protected]> writes: >> >> > Kevin Hilman 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. > > There is one thing I found difficult to share between OMAP-L1x and > DaVinci variants. That is the RAM is map to different physical address. > > For DaVinci Makefile.boot we have > zreladdr-y := 0x80008000 > params_phys-y := 0x80000100 > initrd_phys-y := 0x80800000 > > For OMAP-L1X Makefile.boot we have > zreladdr-y := 0xC0008000 > params_phys-y := 0xC0000100 > initrd_phys-y := 0xC0800000 > > Is there a clean way to consolidate the two?
These makefile variables only affect the creation of the [zu]Image files, not the kernel image itself, which is linked at its virtual address. My primary concern is the ability to have a single kernel image, a single [zu]Image is nice but not mandatory. I don't have any immediate ideas off the top of my head, but this seems like something that would be easy enough to workaround. Come to think of it, I'm pretty sure the zImage code is relocatable anyways, so even if it its linked at 0x80000000 it could be loaded to 0xc0000000 and still work just fine. Would just require using the zImage instead of the uImage in u-boot, and some different u-boot commands. Have you tried that? Just change the Makefile.boot back to the 0x8.... addresses, manually load the zImage to 0xc...... and jump to it. Note, don't try this with uImage and bootm as u-boot will jump to the address in the uImage header (0x80000000) which will be wrong. Kevin _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
