Hi Felipe, > > -- I cannot disclose the name, but it is some major Mobile Company that > is following this approach. One big chunk of DSP Virtual address region is > grabbed during boot time, and after that all the maps/unmaps are managed > from this memory region. > > On Linux? -- Yes. > So the DSP VA passed to Map would be v + chunk_size * i? -- Yes. > > Search a DSP virtual memory region from where? -- Bridge internally does the management of this virtual memory pool. It might get fragmented over time, so based on the size that is requested it will loop through the pool to find the requested continguous DSP VA region. > > -- The onus will be on the Client that reserved the memory to make sure > that the size to map is within the reserved memory block. > > Aha! Yet another place where the kernel is letting user-space screw up > the system. -- :) :). It is a choice between either a. Provide too much configurable options to the Users that they can optimize according to their needs and requirements. b. Don't provide any configurable options to Users and acting like a Black box. With option a. at the benefit of getting configurable option the Users can also use the configurable options to screw up the System :). Examples of (a) are TI's MMU and Mailbox modules and (b) is the IOMMU module and Mailbox module in LO tree. But any ways, coming to Map question, if the User provide size to map greater than reserved memory, the map function fails as this was never reserved. Or it might screw up other Client's reserved memory as this Map request might fall in the other reserved memory region. > > -- The mapping to the physical address is done with the DSPProcessor_Map > function call. > > Yes, but before the Map function the virtual memory has no meaning. > -- Isn't to similar to ARM's virtual memory that doesn't has any meaning until the Physical memory is assigned to it ? 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
