Ameya, > So ideally user space process should touch all the buffers before > sending them to > bridge driver so that page_count is never zero? -- For output buffers from DSP, this is not needed. > Also I didn't understand the meaning of the following message which is > printed > by printk when page_count is less than 1. > > "Trying to fix it up, but a reboot is needed\n" > > Where the fixing effort is happening? -- Good catch. There is no specific reason :). We can remove this. I am not sure but I think this warnings statement was borrowed from one of the Kernel's bad page panic message. Thank you, Best regards, Hari > -----Original Message----- > From: Ameya Palande [mailto:2ameya@xxxxxxxxx] > Sent: Tuesday, April 07, 2009 4:20 PM > To: Kanigeri, Hari > Cc: Guzman Lugo, Fernando; Pandita, Vikram; linux-omap@xxxxxxxxxxxxxxx > Subject: Re: [PATCH 1/4] [OMAPZOOM] [UPDATE] DSPBRIDGE: Memory lock for > DMM. > > Hi Hari, > > On Tue, Apr 7, 2009 at 11:59 PM, Kanigeri, Hari <h-kanigeri2@xxxxxx> > wrote: > > Ameya, > > > >> > >> get_page() function has following check inside it: > >> VM_BUG_ON(atomic_read(&page->_count) == 0); > >> > >> Why we need to repeat it again? > >> I guess we can completely remove following check which is in my > >> opinion completely > >> redundant: > > > > -- This check in get_page is conditional check and this is to catch the > cases when page >count starts with "0", which I think is still a possible > condition if the user space buffer >was never touched. So I am not sure if > we can rely on this. > > Thanks for the explanation :) I missed the point that VM_BUG_ON is a > conditional check. > So ideally user space process should touch all the buffers before > sending them to > bridge driver so that page_count is never zero? > > Also I didn't understand the meaning of the following message which is > printed > by printk when page_count is less than 1. > > "Trying to fix it up, but a reboot is needed\n" > > Where the fixing effort is happening? > > Cheers, > Ameya. -- 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
