Fernando, > -----Original Message----- > From: Guzman Lugo, Fernando > Sent: Friday, July 02, 2010 11:27 AM > To: Kanigeri, Hari; linux-omap@xxxxxxxxxxxxxxx; linux- > kernel@xxxxxxxxxxxxxxx > Cc: ohad@xxxxxxxxxx; hiroshi.doyu@xxxxxxxxx; ameya.palande@xxxxxxxxx; > felipe.contreras@xxxxxxxxx > Subject: RE: [PATCH 8/9] dspbridge: add map support for big buffers > > > > Hi Hari, > > > -----Original Message----- > > From: Kanigeri, Hari > > Sent: Thursday, July 01, 2010 6:36 PM > > To: Guzman Lugo, Fernando; linux-omap@xxxxxxxxxxxxxxx; linux- > > kernel@xxxxxxxxxxxxxxx > > Cc: ohad@xxxxxxxxxx; hiroshi.doyu@xxxxxxxxx; ameya.palande@xxxxxxxxx; > > felipe.contreras@xxxxxxxxx; Guzman Lugo, Fernando > > Subject: RE: [PATCH 8/9] dspbridge: add map support for big buffers > > > > Fernando, > > > > > - for_each_sg(sgt->sgl, sg, sgt->nents, i) > > > - sg_set_page(sg, usr_pgs[i], PAGE_SIZE, 0); > > > + da = iommu_vmap(mmu, da, sgt, IOVMF_ENDIAN_LITTLE | > > > + IOVMF_ELSZ_32); > > > > -- iommu_vmap does the Kernel mapping to the buffers you are mapping to > > DSP MMU. Why do you need Kernel mappings ? > > > > If there is no benefit in maintaining Kernel mapping I would rather call > > iopgtable_store_entry directly to map the entries. > > Where inside iommu_vmap is the mapping done? -- The mapping is done to track down the Device mappings. But since you already have it in dmm.c this is kind of redundant right now, and we might see performance impact due to this. I think it might be good to transition to iovmm when we phase out dmm.c. Few things to take into account transitioning to iovmm approach: - DSPBridge used to have linked list approach to track down the mapped entries and profiling showed it took considerable amount of traversing through the list. Jeff Taylor's algorithm in dmm.c helped to reduce this impact. - How would you manage the Device virtual pool moving to iovmm ? And how about the reservation ? Thank you, Best regards, Hari -- 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
