RE: [PATCH 2/2] DSPBRIDGE: add checking 128 byte alignment for dsp cache line size

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> Do you know of any client that doing ReseveMemory and Map independently?
> How much overhead is there in ReserveMemory?
> What happens if the Map size is different than the ReserveMemory? What
> happens if the size is bigger?

-- 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.

> How much overhead is there in ReserveMemory?
-- The overhead is the ioctls to the Bridge driver and the search that is involved in searching for the DSP virtual address region that meets the size requirement.

> What happens if the Map size is different than the ReserveMemory? What
> happens if the size is bigger?

-- 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.

> In fact I don't even understand what is DSP VA memory. Is that virtual
> memory? 
-- Yes, that is the DSP Virtual address.  

> What meaning is there on virtual memory that has no physical
> memory?

-- The mapping to the physical address is done with the DSPProcessor_Map function call. 

Thank you,
Best regards,
Hari

> -----Original Message-----
> From: Felipe Contreras [mailto:felipe.contreras@xxxxxxxxx]
> Sent: Friday, May 15, 2009 11:59 AM
> To: Kanigeri, Hari
> Cc: Hiroshi DOYU; Menon, Nishanth; linux-omap@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH 2/2] DSPBRIDGE: add checking 128 byte alignment for
> dsp cache line size
> 
> On Fri, May 15, 2009 at 5:54 PM, Kanigeri, Hari <h-kanigeri2@xxxxxx>
> wrote:
> >> >>While we are at it, this new mapping could do
> >> >> PROC_ReserveMemory at the same time so that the user-space
> application
> >> >> doesn't get a chance to modify the pa.
> >> >>
> >> > -- What does PROC_ReserveMemory has to do with pa ?
> >>
> >> Sorry, I don't know what kind of address PROC_ReserveMemory returns
> >> (va?), but I don't see any point in having PROC_ReserveMemory and
> >> PROC_Map as separate ioctls
> >>
> >
> > -- The purpose of PROC_ReserveMemory is for the Bridge clients to grab
> DSP VA memory one time and use the PROC_MapMemory to map the address
> within this
> > reserved memory. So, in a way with proper usage of PROC_ReserveMemory,
> it should be called only one time and subsequent Map/Unmaps from a client
> should happen within this memory region. By following this, you can
> eliminate the overhead of calling redundant reserve/unreserve calls that
> go into the driver.
> 
> Do you know of any client that doing ReseveMemory and Map independently?
> How much overhead is there in ReserveMemory?
> What happens if the Map size is different than the ReserveMemory? What
> happens if the size is bigger?
> 
> In fact I don't even understand what is DSP VA memory. Is that virtual
> memory? What meaning is there on virtual memory that has no physical
> memory?
> 
> --
> 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

[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux