From patchwork Tue Nov 11 18:10:33 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Juergen Borleis X-Patchwork-Id: 5276561 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 2848BC11AC for ; Tue, 11 Nov 2014 18:14:50 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 4175A2013D for ; Tue, 11 Nov 2014 18:14:49 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 14F9920136 for ; Tue, 11 Nov 2014 18:14:48 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1XoFvf-0006aC-BD; Tue, 11 Nov 2014 18:12:35 +0000 Received: from www291.your-server.de ([78.46.156.197]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1XoFvc-0006ZA-5t for linux-arm-kernel@lists.infradead.org; Tue, 11 Nov 2014 18:12:32 +0000 Received: from [88.198.220.131] (helo=sslproxy02.your-server.de) by www291.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1XoFv4-0004YS-IQ; Tue, 11 Nov 2014 19:11:58 +0100 Received: from [95.91.215.74] (helo=[192.168.1.100]) by sslproxy02.your-server.de with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1XoFv1-0005UK-7u; Tue, 11 Nov 2014 19:11:55 +0100 From: Juergen Borleis To: linux-arm-kernel@lists.infradead.org Subject: Samsung/S3C6410/Mini6410: how to handle NAND's "clock off" Date: Tue, 11 Nov 2014 19:10:33 +0100 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <201411111910.34231.juergen@kreuzholzen.de> X-Authenticated-Sender: juergen@kreuzholzen.de X-Virus-Scanned: Clear (ClamAV 0.98.4/19614/Tue Nov 11 18:05:44 2014) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20141111_101232_459363_72B26528 X-CRM114-Status: GOOD ( 12.46 ) X-Spam-Score: 0.0 (/) Cc: Brian Norris , Kukjin Kim , linux-samsung-soc@vger.kernel.org, David Woodhouse , Ben Dooks X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_LOW, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable 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 Hi, the S3C2410 NAND driver [1] can still be used for NANDs attached to an S3C6410 SoC. But this driver has a "nice" feature called "clock off" to save some power while not in use. I tried it here on my Mini6410 platform and it freezes the system. The clock tree is somehow: [...] hclk 4 4 133000000 0 0 hclk_mfc 0 0 133000000 0 0 hclk_mem0 2 2 133000000 0 0 mem0_srom 0 0 133000000 0 0 mem0_nfcon 1 1 133000000 0 0 mem0_onenand0 0 0 133000000 0 0 mem0_onenand1 0 0 133000000 0 0 mem0_cfcon 0 0 133000000 0 0 [...] On the Mini6410 the "mem0_nfcon" clock is the only single user of the "hclk_mem0". And this clock is required to keep the access to the external network device enabled. When the NAND driver disables its clock "mem0_nfcon", the "hclk_mem0" gets also disabled because there is no consumer anymore. The next time the network driver tries to access its device, the SoC freezes. How to prevent this? Can we keep the "hclk_mem0" enabled without an active consumer? Or do we need a dummy consumer? Or do we need to request for "hclk_mem0" when at least one external device is attached? Or should we remove the "clock stop" feature for at least the S3C6410 SoC? With the patch below I was able to reproduce the behavior: Author: Juergen Borleis Date: Mon Nov 10 23:35:06 2014 +0100 ARM/S3C6410/NAND: add clock alias to keep an old driver alive This change enables the existing S3c2410.c driver for the S3C6410. But keep in mind to disable the CONFIG_MTD_NAND_S3C2410_CLKSTOP when using this driver! Why? The access to external devices depends on a running "hclk_mem0" clock. As the NAND controller was the only single user of it, it disables it, when it disables its owm clock to save power. This locks the system. m( Signed-off-by: Juergen Borleis jbe [1] drivers/mtd/nand/s3c2410.c diff --git a/drivers/clk/samsung/clk-s3c64xx.c b/drivers/clk/samsung/clk-s3c64xx.c index 0f590e5..f7d2d57 100644 --- a/drivers/clk/samsung/clk-s3c64xx.c +++ b/drivers/clk/samsung/clk-s3c64xx.c @@ -404,6 +404,7 @@ static struct samsung_clock_alias s3c64xx_clock_aliases[] = { ALIAS(PCLK_IIS0, "samsung-i2s.0", "iis"), ALIAS(PCLK_AC97, "samsung-ac97", "ac97"), ALIAS(PCLK_TSADC, "s3c64xx-adc", "adc"), + ALIAS(MEM0_NFCON, NULL, "nand"), ALIAS(PCLK_KEYPAD, "samsung-keypad", "keypad"), ALIAS(PCLK_PCM1, "samsung-pcm.1", "pcm"), ALIAS(PCLK_PCM0, "samsung-pcm.0", "pcm"),