On Wed, Feb 10, 2010 at 05:06:26AM +0100, ext Guzman Lugo, Fernando wrote: > >At this point there's an obvious question; what's the point of > >reserving a memory region and not mapping it? > > > >I remember the answer from Hari was: some clients prefer to reserve a > >big region once, and map parts of it continuously. I have my doubts > >that the use-case even works with the current code-base. But assuming > >it does work, your proposed changes would break it. > > Resource cleanup does not support that even without my proposed changes. Aha! I suspected it :P > I just proposed a solution which fixes two issues in one patch. > Moreover if this change is merged when the second issue be fixed this > patch will not needed anymore, so why don't merge the patch which > fixes both errors at this moment? simple patches > complicated patches Personally I think your patches should be a continuation to the patches I just proposed. If nobody wants to split these patches, I'll gladly do so. > >+ u32 dsp_res_addr = p_cur_res->ulDSPResAddr; > >+ > >+ status = PROC_UnMap(p_cur_res->hProcessor, > >+ (void *)p_cur_res->ulDSPAddr, p_ctxt); > > > >It would be much easier to merge the two functions into one. > > Yes, I am agreed. Good. Perhaps we can start moving reserve/unreserve functionality to map/unmap, and eventually depreate the former. Cheers. -- 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
