From patchwork Mon Jun 15 22:42:54 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kevin Hilman X-Patchwork-Id: 30443 X-Patchwork-Delegate: paul@pwsan.com Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by demeter.kernel.org (8.14.2/8.14.2) with ESMTP id n5FMh6Ph028848 for ; Mon, 15 Jun 2009 22:43:07 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751147AbZFOWnA (ORCPT ); Mon, 15 Jun 2009 18:43:00 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752299AbZFOWnA (ORCPT ); Mon, 15 Jun 2009 18:43:00 -0400 Received: from qw-out-2122.google.com ([74.125.92.26]:59721 "EHLO qw-out-2122.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751147AbZFOWm7 (ORCPT ); Mon, 15 Jun 2009 18:42:59 -0400 Received: by qw-out-2122.google.com with SMTP id 5so2492642qwd.37 for ; Mon, 15 Jun 2009 15:43:01 -0700 (PDT) Received: by 10.224.19.194 with SMTP id c2mr7785390qab.193.1245105781607; Mon, 15 Jun 2009 15:43:01 -0700 (PDT) Received: from localhost ([216.254.16.51]) by mx.google.com with ESMTPS id 6sm294179qwd.12.2009.06.15.15.43.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 15 Jun 2009 15:43:01 -0700 (PDT) From: Kevin Hilman To: linux-omap@vger.kernel.org Cc: Mike Chan , Richard Woodruff Subject: [PATCH -pm 1/2] SDRC: check for stuck DLL state machine and kick Date: Mon, 15 Jun 2009 15:42:54 -0700 Message-Id: <1245105775-28844-2-git-send-email-khilman@deeprootsystems.com> X-Mailer: git-send-email 1.6.3.2 In-Reply-To: <1245105775-28844-1-git-send-email-khilman@deeprootsystems.com> References: <1245105775-28844-1-git-send-email-khilman@deeprootsystems.com> Sender: linux-omap-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-omap@vger.kernel.org From: Richard Woodruff I'm thinking DLL state is an exceptional condition which happens based on some wrong early programming when initially setting DLL up. Some kind of race between idle features and lock happens early on. This patch recognizes the issue and moves state machine into locked state. Its my guess the kick case won't be executed that often. As long as DLL is not on you can mess with idle state. When its on to mess with DDR control you need to be in self-refresh and not making accesses... like in dvfs code. Tested-by: Mike Chan --- arch/arm/mach-omap2/sleep34xx.S | 22 ++++++++++++++++++++-- 1 files changed, 20 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S index aedcf94..c469bbe 100644 --- a/arch/arm/mach-omap2/sleep34xx.S +++ b/arch/arm/mach-omap2/sleep34xx.S @@ -595,20 +595,38 @@ wait_sdrc_ok: ldr r5, [r4] bic r5, r5, #0x40 str r5, [r4] -wait_dll_lock: - /* Is dll in lock mode? */ +is_dll_in_lock_mode: ldr r4, sdrc_dlla_ctrl ldr r5, [r4] tst r5, #0x4 bxne lr /* wait till dll locks */ +wait_dll_lock_timed: ldr r4, sdrc_dlla_status + mov r6, #0x2000 +wait_dll_lock: + subs r6, r6, #0x1 + beq kick_dll ldr r5, [r4] and r5, r5, #0x4 cmp r5, #0x4 bne wait_dll_lock bx lr + /* Kick DLL state machine if lock not started */ +kick_dll: + ldr r4, sdrc_dlla_ctrl /* get dlla addr */ + ldr r5, [r4] /* grab value */ + mov r6, r5 /* save value */ + orr r6, r6, #0x10 /* dllidle on */ + str r6, [r4] + dsb + bic r6, #0x10 /* dllidle off */ + str r6, [r4] + dsb + str r6, [r4] /* restore old value */ + b wait_dll_lock_timed + cm_idlest1_core: .word CM_IDLEST1_CORE_V sdrc_dlla_status: