> -----Original Message----- > From: Felipe Contreras [mailto:felipe.contreras@xxxxxxxxx] > Sent: Tuesday, August 24, 2010 2:14 PM > To: Guzman Lugo, Fernando > Cc: Kanigeri, Hari; linux-omap@xxxxxxxxxxxxxxx; > linux-kernel@xxxxxxxxxxxxxxx; ohad@xxxxxxxxxx; > hiroshi.doyu@xxxxxxxxx; ameya.palande@xxxxxxxxx; > felipe.contreras@xxxxxxxxx > Subject: Re: [PATCH 8/9] dspbridge: add map support for big buffers > > On Tue, Aug 24, 2010 at 10:05 PM, Guzman Lugo, Fernando > <fernando.lugo@xxxxxx> wrote: > >> I've heard there are some problems regarding DMM, and > since you say > >> you have already done the changes, and since iommu > migration is not > >> yet ready AFAIK, it might make sense to go for option b). > >> > >> Anyway, thanks for the clarification :) > > > > But DMM is used in this momment, it is after the IOMMU > migration When > > DMM is not needed anymore. So we need to go for option a). > > Oh, I actually meant the DMM pool. > > a) 1. Migrate to iommu, 2. Remove DMM completely > b) 1. Remove DMM pool, 2. Migrate to iommu 3. Remove DMM completely Ok, what is the issue with DMM pool? The issue I see removing DMM pool in this moment and making all the DMM Available (from 0x11000000 to 0xFFFFFFFF omap3 case) that is: The DMM module allocates a list of "struct map_page" elements base on DMM_POOL_SIZE to keep track of memory reserved and mapped. Memory allocated = DMM_POOL_SIZE / PAGE_SIZE * sizeof(struct map_page); So making all memory avalible it will increase the memory used for DMM Module and it could be quite significant. Iovmm.c module, the list is increased dynamically when it is needed so It does no have that problem. Then when the migration is done and Iovmm.c module is used the DMM_POOL_SIZE can be removed without issues. Regards, Fernando. > > -- > Felipe Contreras > -- 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
