From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754460Ab0IOPkF (ORCPT ); Wed, 15 Sep 2010 11:40:05 -0400 Received: from arroyo.ext.ti.com ([192.94.94.40]:57130 "EHLO arroyo.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753186Ab0IOPkB convert rfc822-to-8bit (ORCPT ); Wed, 15 Sep 2010 11:40:01 -0400 From: "Ramirez Luna, Omar" To: venki kaps , "Kanigeri, Hari" , "ameya.palande@nokia.com" , "Guzman Lugo, Fernando" , "Hebbar, Shivananda" , "Ramos Falcon, Ernesto" , "felipe.contreras@gmail.com" , "Anna, Suman" , "Gupta, Ramesh" , "Gomez Castellanos, Ivan" , "ext-andriy.shevchenko@nokia.com" , "Uribe de Leon, Armando" , "Chitriki Rudramuni, Deepak" , "Menon, Nishanth" , "ext-phil.2.carmody@nokia.com" , "ohad@wizery.com" , "devel@driverdev.osuosl.org" , "linux-omap@vger.kernel.org" , "linux-kernel@vger.kernel.org" Date: Wed, 15 Sep 2010 10:39:49 -0500 Subject: RE: OMAP3 DSP MMU fault + off mode issue Thread-Topic: OMAP3 DSP MMU fault + off mode issue Thread-Index: ActU3bvFG7B2ud4SRmG+FK48vJncyQADHRww Message-ID: <27F9C60D11D683428E133F85D2BB4A530450C3265B@dlee03.ent.ti.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org venki kaps wrote: ... > > My problem is resolved.GPtimer7 was not reset during the MMU FAULT > occurrence before the first power cycle. So this pending interrupt is > preventing the system sleep entry. > Now it works fine after resetting Gptimer7 in pm suspend path. > That's doesn't sound right, why the problem is not occurring after the first suspend-resume cycle. DSP is in charge of clearing the overflow interrupt and if it is doing it after the first transition to Core OFF, why wouldn't be doing it for the first one. Moreover from the logs sent internally (since it is the same issue and oddly the same resolution), the trace log dump printed is generated in the dsp after clearing the interrupts, so the problem could be the gptimer is configured to autoreload instead of oneshoot or the dsp write is not posted to clear the interrupt (which might be valid issues), but also they could happen after the first transition to OFF. I'm sorry if I didn't ask you for logs but I was seeing this issue internally (and assumed you'll be in the same team of people :)), and given that more information was posted there than here..., but still, if available send the changes you have made. Regards, Omar