From patchwork Thu Jan 7 18:07:01 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Lindgren X-Patchwork-Id: 7978831 Return-Path: X-Original-To: patchwork-linux-omap@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id BA6C7BEEE5 for ; Thu, 7 Jan 2016 18:07:10 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id CB70C20149 for ; Thu, 7 Jan 2016 18:07:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D23E220138 for ; Thu, 7 Jan 2016 18:07:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752346AbcAGSHI (ORCPT ); Thu, 7 Jan 2016 13:07:08 -0500 Received: from muru.com ([72.249.23.125]:53841 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752026AbcAGSHH (ORCPT ); Thu, 7 Jan 2016 13:07:07 -0500 Received: from atomide.com (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id C59248392; Thu, 7 Jan 2016 18:07:33 +0000 (UTC) Date: Thu, 7 Jan 2016 10:07:01 -0800 From: Tony Lindgren To: Ivaylo Dimitrov Cc: Sebastian Reichel , Pali =?utf-8?B?Um9ow6Fy?= , linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Brian Hutchinson , Paul Walmsley , Roger Quadros , Aaro Koskinen , pavel@ucw.cz, Nishanth Menon Subject: Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug Message-ID: <20160107180700.GN12777@atomide.com> References: <20160104174001.GD12777@atomide.com> <568AC0F9.2010304@gmail.com> <20160105041356.GE12777@atomide.com> <20160105084947.GG22661@pali> <20160105224929.GF12777@atomide.com> <20160106174039.GA14271@earth> <20160106174713.GL12777@atomide.com> <568D5669.4040801@gmail.com> <20160106182650.GM12777@atomide.com> <568D5F54.7040900@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <568D5F54.7040900@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-omap-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-omap@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, 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 * Ivaylo Dimitrov [160106 10:39]: > Hi, > > On 6.01.2016 20:26, Tony Lindgren wrote: > > > > >Hmm. Care to verify that your onenand really gets detected at 83 MHz like > >your earlier logs show? Below is a patch that should show it. > > before the corruption appeared, I looked a couple of times in syslog and the > freq there was 83MHz. Including after I disabled CONFIG_OMAP_GPMC_DEBUG. OK well at least that part of the bug is fixed then. > >Also, do things now work reliably for you with CONFIG_OMAP_GPMC_DEBUG > >enabled? Or does that also produce corruption after few reboots? > > CONFIG_OMAP_GPMC_DEBUG is disabled, shall I enable it? Yes please. > Where am I supposed to get the output from ^^^ if rootfs become corrupted? > The problem appears after poweroff/restart when it is already too late to > get the syslog. Hmm good point. Can you boot with root on MMC? So far no luck here reproducing the corruption here with my fix applied. > BTW, did you compare all the GPMC registers with and without > HWMOD_INIT_NO_RESET? Well the timings now for me both with and without GPMC reset are: cs0 GPMC_CS_CONFIG1: 0xfb001201 cs0 GPMC_CS_CONFIG2: 0x00101000 cs0 GPMC_CS_CONFIG3: 0x00020200 cs0 GPMC_CS_CONFIG4: 0x10001003 cs0 GPMC_CS_CONFIG5: 0x020f1313 cs0 GPMC_CS_CONFIG6: 0x8f050000 These timings also match the current mainline timings without the fix I posted when CONFIG_OMAP_GPMC_DEBUG is enabled. The nolo set timings I have are: cs0 GPMC_CS_CONFIG1: 0xfb001201 cs0 GPMC_CS_CONFIG2: 0x00101000 cs0 GPMC_CS_CONFIG3: 0x00020200 cs0 GPMC_CS_CONFIG4: 0x10001002 <- OEONTIME is still different in nolo cs0 GPMC_CS_CONFIG5: 0x020f1313 cs0 GPMC_CS_CONFIG6: 0x8f050000 So there seems to be OEONTIME difference. Once the legacy boot is gone, we can probably remove the OEONTIME calculations and rely on the dts provide values as it seems that currently the dts value is ignored in gpmc_calc_sync_read_timings(). To dump your nolo provided timings, you can add the following line to gpmc_probe_onenand_child() before gpmc_onenand_init: gpmc_cs_show_timings(gpmc_onenand_data->cs, "before gpmc_cs_program_settings"); Note that will show the wrong GPMC default values after reset unless you have CONFIG_OMAP_GPMC_DEBUG enabled. Then below is a better debug patch to dump out the values after reset. Note that in that case the above "before" timings must be ignored. Regards, Tony 8< -------------------- --- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html --- a/arch/arm/mach-omap2/gpmc-onenand.c +++ b/arch/arm/mach-omap2/gpmc-onenand.c @@ -153,6 +153,8 @@ static int omap2_onenand_get_freq(struct omap_onenand_platform_data *cfg, freq = 0; } + gpmc_cs_show_timings(cs, "before gpmc_cs_program_settings"); + return freq; } --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c @@ -2150,8 +2150,7 @@ static struct omap_hwmod omap3xxx_gpmc_hwmod = { .clkdm_name = "core_l3_clkdm", .mpu_irqs = omap3xxx_gpmc_irqs, .main_clk = "gpmc_fck", - /* Skip reset for CONFIG_OMAP_GPMC_DEBUG for bootloader timings */ - .flags = HWMOD_NO_IDLEST | DEBUG_OMAP_GPMC_HWMOD_FLAGS, + .flags = HWMOD_NO_IDLEST, }; /* --- a/drivers/memory/omap-gpmc.c +++ b/drivers/memory/omap-gpmc.c @@ -1987,7 +1987,7 @@ static int gpmc_probe_generic_child(struct platform_device *pdev, if (ret < 0) goto err; - gpmc_cs_show_timings(cs, "before gpmc_cs_program_settings"); + dev_info(&pdev->dev, "GPMC reset, not showing default timings\n"); ret = gpmc_cs_program_settings(cs, &gpmc_s); if (ret < 0) goto err;