From patchwork Mon Jan 6 10:31:42 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tushar Behera X-Patchwork-Id: 3437021 Return-Path: X-Original-To: patchwork-linux-samsung-soc@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 5B4CF9F163 for ; Mon, 6 Jan 2014 10:31:49 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 89CAD20165 for ; Mon, 6 Jan 2014 10:31:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 04F3B20166 for ; Mon, 6 Jan 2014 10:31:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753182AbaAFKbn (ORCPT ); Mon, 6 Jan 2014 05:31:43 -0500 Received: from mail-ob0-f174.google.com ([209.85.214.174]:56082 "EHLO mail-ob0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752082AbaAFKbm (ORCPT ); Mon, 6 Jan 2014 05:31:42 -0500 Received: by mail-ob0-f174.google.com with SMTP id wn1so18086585obc.19 for ; Mon, 06 Jan 2014 02:31:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=sS3O72EPd27R/3NYkVpSEOEAHGEGp/ivlDZM5BH9s6o=; b=XbagplZ/jdyLNmfN8Q68+Ab0yau3XtIuGHjpa2UqDI/STs+yPEYw9RL5rGW3yKc0db wDvxB4fhY2mHH5YHnN1dw+zVIZbZjYzaW0Y7UI8SZwrUsM2H59Bjhz7IEwo+BBbXBj72 8p2s51Iyre04Cbc+dqL8VBPtN4toJnkMM83262XH/dhjNSNlcjX77J+W0cbZboIU5FXA xn+mYwlP+jA0z9xzEZwtofROC3p/UdfcsGKbkMZxXvtLKX2jEh9amxNz2N2dNqv9jD2s yeAvIxu+hghjBnWz/3wME1EeL+Axc3YTpWZkJQKQZhZfc60VDNJUJMgTov9hkJEfkob6 2n1g== X-Gm-Message-State: ALoCoQltGDs4v1Gi/dS9wWLt6ypRLnnG4IqlK2PjUYfjCcwFtt5WUtJOXBnNsULM89x8f8Y4cfke MIME-Version: 1.0 X-Received: by 10.182.87.69 with SMTP id v5mr163809obz.77.1389004302326; Mon, 06 Jan 2014 02:31:42 -0800 (PST) Received: by 10.60.157.229 with HTTP; Mon, 6 Jan 2014 02:31:42 -0800 (PST) In-Reply-To: <2428340.zXRbG18t7N@amdc1227> References: <201401031437.10624.arnd@arndb.de> <2428340.zXRbG18t7N@amdc1227> Date: Mon, 6 Jan 2014 16:01:42 +0530 Message-ID: Subject: Re: Boot hang on Origen with (!SMP && CPU_IDLE) From: Tushar Behera To: Tomasz Figa Cc: Arnd Bergmann , Kyungmin Park , Kgene Kim , linux-samsung-soc Sender: linux-samsung-soc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-samsung-soc@vger.kernel.org X-Spam-Status: No, score=-7.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 3 January 2014 19:28, Tomasz Figa wrote: > On Friday 03 of January 2014 14:37:10 Arnd Bergmann wrote: >> On Friday 03 January 2014, Tushar Behera wrote: [ ... ] >> Hmm, the boot log contains no message about the l2 cache controller getting >> initialized, which means that l2x0_of_init probably failed before calling >> l2x0_init. It also seems that the dts files distributed with the kernel >> are lacking nodes for the l2x0 device, which is indeed a perfectly good >> explanation although it doesn't explain at all why it ever worked on >> any system with my patch. >> >> Can you check if there is a correct cache controller node in your device >> tree, and whether it works when you add one? If so, we should probably >> add a couple of stable backport patches to the dts files. It would also The device tree node for l2x0 device was missing. After adding a node as below I can start booting Origen board. > > Tushar, do you maybe also have CONFIG_CACHE_L2X0 enabled? > Yes, this config option is enabled. If this is disabled, I don't see this problem. > Generally I can see two different issues here: > > 1) Broken handling of L2 cache in plat-samsung/sleep.S. It assumes that > whenever CONFIG_CACHE_L2X0 is enabled, L2 cache is enabled too. > > This needs to go away. On normal resume from sleep, there is no need to > do anything with L2X0 at such early stage. This reinitialization can be > safely done later, by calling generic outer_resume(). > > The problem shows up when you look at AFTR and LPA idle modes. They keep > L2 cache contents, but L2X0 registers must be restored to let the cache > operate normally. This must happen early enough to keep cache data > consistent. Still, the code doing this must consider whether the cache > was enabled before entering AFTR/LPA and whether secure firmware is used > (see below), so this is a bit tricky. > > 2) There is no L2 cache controller node in Exynos4*.dtsi. > > It should be added, but L2 cache can't be enabled on all boards yet, > since on boards where secure firmware is enabled, special configuration > involving SMC calls is required. Patches for this are queued on my work > queue, but it's quite tricky due to 1), which needs to consider whether > secure firmware is enabled or not. > In that case, would it be ok to add the node for Origen board only? diff --git a/arch/arm/boot/dts/exynos4210-origen.dts b/arch/arm/boot/dts/exynos4210-origen.dts index 1a12fb2..675f323 100644 --- a/arch/arm/boot/dts/exynos4210-origen.dts +++ b/arch/arm/boot/dts/exynos4210-origen.dts @@ -32,6 +32,13 @@ + l2-cache-controller@10502000 { + compatible = "arm,pl310-cache"; + reg = <0x10502000 0x1000>; + cache-unified; + cache-level = <2>; + }; + >> be a good time to get rid of the L2_AUX_VAL and L2_AUX_MASK defines and >> just read the respective settings from DT. Ok.