Sripal, > Currently, display driver maps the video buffers to userspace with > VM_RESERVED flag and pgprot_writecombine(). We are considering changing > pgprot_writecombine() to pgprot_noncached() to eliminate the need of all > cache maintenance overheads for video buffers. > -- Is this change in the current LO kernel ?
I agree there is an overhead of flushing the cache by calling get_user_pages function. But there is some additional stuff that this function does and I am afraid that by-passing this function call for a Buffer that has VM_RESERVED flag and the BUFFERABLBE flags might create issues. The only reason get_user_pages is not used for the buffer that has VM_IO flag set is get_user_pages fails if this flag is set for the buffer. I am not sure if it is safe to by-pass the get_user_pages function call for buffer that has VM_RESERVED flag set though. Thank you, Best regards, Hari > -----Original Message----- > From: Bagadia, Sripal > Sent: Thursday, June 11, 2009 11:24 AM > To: Hiroshi DOYU; Ramirez Luna, Omar > Cc: [email protected]; [email protected]; Menon, Nishanth; > Kanigeri, Hari; [email protected] > Subject: RE: [RFC][PATCH] DSPBRIDGE: Video Playback Cache Optimization > > > Would it be possible to tell the case/path, where > L_PTE_CACHEABLE/L_PTE_BUFFERABLE is set with VM_IO/VM_RESERVED ? > > Currently, display driver maps the video buffers to userspace with > VM_RESERVED flag and pgprot_writecombine(). We are considering changing > pgprot_writecombine() to pgprot_noncached() to eliminate the need of all > cache maintenance overheads for video buffers. > > Regarding Felipe's comment: > > L_PTE_BUFFERABLE is obsolete, isn't it? L_PTE_MT_BUFFERABLE should be > used instead. > > I was working on 2.6.27.10, and agree that this needs to be updated for > newer kernels. > > > Regards, > Sripal > > -----Original Message----- > From: Hiroshi DOYU [mailto:[email protected]] > Sent: Thursday, June 11, 2009 2:16 AM > To: Ramirez Luna, Omar > Cc: [email protected]; [email protected]; Menon, Nishanth; > Bagadia, Sripal; Kanigeri, Hari; [email protected] > Subject: Re: [RFC][PATCH] DSPBRIDGE: Video Playback Cache Optimization > > From: Hiroshi DOYU <[email protected]> > Subject: Re: [RFC][PATCH] DSPBRIDGE: Video Playback Cache Optimization > Date: Wed, 10 Jun 2009 10:25:39 +0300 (EEST) > > > From: "ext Ramirez Luna, Omar" <[email protected]> > > Subject: RE: [RFC][PATCH] DSPBRIDGE: Video Playback Cache Optimization > > Date: Wed, 10 Jun 2009 01:18:29 +0200 > > > > > Hi, > > > > > > [sending as plain text to l-o] > > > > > > Could you please comment on this patch. > > > > > > From: Sripal Bagadia <[email protected]> > > > Date: Tue, 9 Jun 2009 16:05:09 -0500 > > > Subject: [PATCH] DSPBRIDGE: Video Playback Cache Optimization > > > > > > Avoid get_user_pages cache flush overheads for uncached & reserved > > > buffers (e.g. display & camera buffers). > > > > Would it be possible to tell the case/path, where no > > L_PTE_CACHEABLE/L_PTE_BUFFERABLE is set with VM_IO/VM_RESERVED ? > > To be correct, > "where L_PTE_CACHEABLE/L_PTE_BUFFERABLE is set with VM_IO/VM_RESERVED" > > > > > > > Signed-off-by: Sripal Bagadia <[email protected]> > > > --- > > > drivers/dsp/bridge/wmd/tiomap3430.c | 4 +++- > > > 1 files changed, 3 insertions(+), 1 deletions(-) > > > > > > diff --git a/drivers/dsp/bridge/wmd/tiomap3430.c > > > b/drivers/dsp/bridge/wmd/tiomap3430.c > > > index 7a9603d..a2f32e8 100644 > > > --- a/drivers/dsp/bridge/wmd/tiomap3430.c > > > +++ b/drivers/dsp/bridge/wmd/tiomap3430.c > > > @@ -1461,7 +1461,9 @@ static DSP_STATUS WMD_BRD_MemMap(struct > > > WMD_DEV_CONTEXT *hDevContext, > > > goto func_cont; > > > } > > > > > > - if (vma->vm_flags & VM_IO) { > > > + if ((vma->vm_flags & VM_IO) | ((vma->vm_flags & VM_RESERVED) > > > +&& > > > + (~pgprot_val(vma->vm_page_prot) & L_PTE_CACHEABLE) > > > +&& > > > + (~pgprot_val(vma->vm_page_prot) & > > > +L_PTE_BUFFERABLE))) { > > > numUsrPgs = ulNumBytes / PG_SIZE_4K; > > > mpuAddr = ulMpuAddr; > > > DBG_Trace(DBG_LEVEL4, > "WMD_BRD_MemMap:numOfActualTabEntries=%d," > > > -- > > > 1.6.2.4 > > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
